Reader relationship management at the Facebook Journalism Project hack day
The Facebook Journalism Project held its first UK hackathon last week, and Trinity Mirror sent along a team of developers and journalists to participate.
We did a little preparation before the hack day, but had no solid idea of what to work on. After a brief discussion over breakfast, we settled on trying to solve a fairly simple problem:
The feedback forms we use at the bottom of articles are effective for gathering stories from readers, but they don’t work on Facebook Instant Articles or AMP
However, as we looked into the processes behind this method of gathering reader feedback, and plotted out the workflows with editorial members of the team, we came across deeper problems:
- The workflow for creating these forms is cumbersome, and is Yet Another Tool for journalists to learn, use and forget
- The forms don’t integrate very well with our websites and other products
- The forms don’t integrate with our CMS or other internal systems
Looking beyond these basic issues, we saw an array of options for readers who want to connect with our editorial teams — not just forms embedded in articles, but also:
- Email — direct and group mailboxes
- Article comments
- Facebook, Twitter and other social networks
- Facebook Messenger, Whatsapp and other messaging apps
- Phone and voicemail
So there are multiple tools to log into constantly to stay on top of everything, phones ringing, notifications going off all over the place, emails stacking up, no way to filter reader feedback by type, urgency or quality, and editorial teams have to keep writing more articles. And (generally speaking) the key metric of their jobs is the last one.
With all the talk about trust in the news industry, treating readers well should be at the core of what we do. In retail, the customer comes first; in the situation above, this seems inverted, which can’t be good for reader perceptions of any publisher.
Our narrow mission statement at the start of the day was:
To create a publisher-focused embedded form replacement to make it easier for users to submit stories / multimedia / tips on whatever platform they consume our content, and for journalists to assess the value of that content
However that had expanded/contracted by the end of the day to:
Making feedback better for journalists and readers across all platforms
The diagram below shows a rough idea of the proposed ideal workflow to address these challenges.
The core element is a dashboard that collates feedback across all of the reader touchpoints, enabling editorial users to log into one tool to see all feedback, and filter based on importance, subject, sentiment or recency, across all platforms.
Having been inspired by seeing some of the upcoming capabilities of Google Cloud Platform’s Machine Learning stack earlier in the week, I was keen to get some form of AI in the solution. Using the various APIs to parse and help categorise and prioritise reader input seemed as if it could help tackle the issue of large volumes of feedback for small, time-poor editorial teams.
Our hack started with hacking together a basic form creation replacement. For this we forked and customised a Github project which had the basic elements in place.
We then whipped up a basic app around it (using the Mojolicious framework) to save the form created in a static HTML file. The form can then be embedded into an article using the iframe code returned. (We looked into piping this directly into our CMS, but had issues with the wifi on the day).
We then hooked up Google Cloud’s Natural Language Processing capabilities to extract sentiment and entities from any messages received, and presented them in the dashboard view below.
To illustrate using the tool beyond simple form feedback, we also created a basic script to pull the latest messages from our Facebook Page inbox, and run these through the NLP APIs too. Although the information pulled through is quite basic, it shows how it might be helpful to see this information in one place.
The code for the hack can be found on Github:
Many businesses spend a lot of time with Consumer Relationship Management tools to better understand and communicate with their users. A ‘Reader Relationship Management’ tool would aim to do the same for publishers.
There are inevitably pitfalls. It’s likely to suffer from the CRM paradox, so it could “occasionally lead to favouritism within an audience” (although that may happen naturally anyway), and it would potentially place another filter between journalists and their audiences. However, if efficiencies can be made by saving journalists time in researching and responding to readers, there should be an overall improvement in communication.
The tool we put together was just a hack, but with further thought and work it could help publishers have a better go at relationship management between readers and writers.