Analytics on the Open Social Web

I’ve been spending a lot of time thinking about analytics on the open social web. I would love to hear how others approach this topic, and share my own perspective.

Engagement

Engagement is an integral component of communication. No matter the form or scale of the communication, almost everyone who participates is looking for engagement of some kind. Whether you’re talking in-person or communicating over technology, in a one-to-one discussion or in a posting publicly, this engagement matters. Without it, you may as well be talking to a brick wall.

Just as communication has many different forms, so too does engagement, both in terms of what is available and what is important to the participants. The best engagement is often a return of communication; “responses” or “replies”. But there is also plenty of engagement (that is relied on more as we reach larger scales) that just lets us know we’ve been heard, or listened to. In person we might be looking for eye contact and nods. Online, this translates to read receipts or view counts.

Online publishing, an important form of communication, is no different when it comes to the need for engagement. In the traditional open web, creators would publish to their website, that users would then visit. In that relationship the creator could measure engagement directly, and track the metrics that were most important to them. In traditional social networks, the platforms are the ones who can measure engagement, and they share a portion of this back to creators. Then we have the open social web that promises creators with more power. Yet ironically, this great ecosystem for creators currently provides the least amount of engagement data and tools for measurement to those creators.

The current state

At the moment in both the ActivityPub and AT Protocol ecosystems, there are some limited engagement signals that are available to the content creator; replies, follows, likes and quotes. And that is exactly where almost every platform in both ecosystems stops. We don’t stop here because that is all the metrics that are available, or useful to creators. We’ve been stopping here because we’ve been focused on the public authored events that work so well in these ecosystems, and these are the limited metrics that fit that model. As soon as we reach for more engagement analytics, we will require a level of privacy and trust that has just been a harder hurdle to overcome.

When to go further

The privacy concerns are solvable, so we need to decide as an ecosystem when these additional analytics should be provided. There are many communities, large and small that make up the open social web ecosystems, each which may have different opinions on these metrics. For example, I’ve seen several smaller communities that are focused on engagement within that community, and they argue that things like view metrics are not needed, or even harmful to what they are trying to create. One of the great things about building on the open social web is that those communities don’t have to track or show these metrics for local posts. I expect many ActivityPub servers with local posts and some AT Protocol communities using custom lexicons or permissioned spaces will operate under this model.

But there will also be many communities that will benefit from analytics like view metrics. Any community that benefits from these metrics, or any participating with others who do, should provide them. Recording detailed analytics for local posts, or displaying those metrics, is up to that local community. But if a community benefits from external content, whether from ActivityPub federation or public AT Protocol content, sharing engagement metrics back to the creator is a reasonable exchange of value. Even most communities that don’t want to show these metrics internally will still benefit from knowing how often their content was viewed elsewhere.

We could, in theory, implement a way for creators to express whether they want these analytics returned in exchange for their content. This way servers/apps could choose to show the content and support the analytics, or exclusively use other content. If this is the way it unfolds in the ecosystem I’ll get behind it, but I’d strongly argue that we should just assume the desire for metrics by default. By defaulting to sharing we, we empower creators and provide them with the choice of how and when to utilise the data. In either approach, we should still prepare to support sharing more advanced engagement analytics in a suitable way.

What analytics to share

If we’re preparing to provide analytics we need to get a little clearer on what we’re sharing, and define the boundaries by establishing what we won’t be sharing. User privacy is extremely important, so creators should never be given analytics that would let them track or target individuals. We’ll not be sharing the viewing user's id, providing cookie tracking or client side pings to the creator, or even sending individual pings on each view. All of these are mechanisms that may work within a platform with appropriate privacy, but these don’t hold up to the reduced trust models in open ecosystems. So first and foremost, we will need to rely on the displaying surfaces (app, server, etc) to collect analytics, then share them in aggregate back to the creator.

Analytics metrics shared in other ecosystems range from simplistic (e.g, views) to more advanced (linger time, scroll depth, etc). The open social web ecosystem should strive for some consensus on the metrics and dimensions that different display surfaces are expected to provide, or minimums for usage of the content. But this will take both time, and experimentation by parties in the ecosystem, especially around things like levels of demographics to share. I’ll certainly be watching with interest, and I encourage display surfaces to just go try things out. But to help continue this discussion, let’s assume at a minimum, we provide creators with view count metrics by the display surface as a dimension.

How to provide this to creators

In the open social web, content creators don’t have to go to many different platforms to post, their posts live on their home server or PDS and travel out from there. Similarly I believe content creators shouldn’t have to go to many different platforms to see their engagement analytics. These analytics should come back to that same home server / PDS. Exactly how that works depends on the protocol.

AT Protocol
The upcoming permissioned spaces in AT Protocol are a fantastic mechanism to deliver engagement analytics. Creators should have a space for analytics under their own DID, hosted on their own PDS. Display surfaces are responsible for writing the metrics to this space (in their respective PDS’s), and can do so without having a closer relationship with the creator, but the creators maintain control over the access to this data. The ecosystem is sure to see specialised AppViews emerge to allow creators to view and draw insights from this data, and creators can pick and choose which ones they use.

To keep it simple, there should be nothing a creator needs to do or configure in order to receive the metrics. There may be steps required if and when the creator wants to view or control access to those metrics, but when they do so the entire backlog should be available to them. Again the permissioned spaces provide a great way to manage this. Content displaying apps and display surfaces can just write back to a default space (e.g; ats://creator.did.identity.provider/community.lexicons.analytics.space/self), and it doesn’t matter if the space actually exists yet or not. When the creator goes to view the metrics, likely through an analytics appview, that appview can help the user create the space and start fetching all the analytics the display surfaces have already written. There’s already been discussions in the developer community around not bundling too much into a single space, and instead we should be using many spaces under a single DID. But for analytics specifically, I believe having one default space for analytics is much cleaner, especially for supporting the long tail of display surfaces.

ActivityPub
The ActivityPub ecosystem has had mechanisms for private delivery from the start, with the inbox model ready to receive this data now. Though with the disjointed server architecture, this will require each server to implement the handling of analytics data individually. So it doesn’t support unified viewers natively out of the box in the same way as AT Protocol. Servers can then either implement the full analytics viewing features, or provide mechanisms for users to use third party apps. But the delivery is clean and simple in ActivityPub.

Data standardisation

While the community must work to reach consensus on data schema, several core components are necessary for interoperability. For starters, on ActivityPub we will need to define the container early on. Even before we have widespread adoption or ways to view the analytics, we need to make sure ActivityPub servers know what the object type will be, even if just to put it into storage for now. We can solve other parts as we go, but aligning on object types helps to prevent this type of data loss.

In AT Protocol, the data container isn’t as vital as the space it goes into. If at the extreme, every single AppView that displayed content wrote a completely different lexicon, sure it wouldn’t be ideal, but at least the content would be there for the creator. While a standardised container lexicon offers benefits, platforms should proceed with experimentation with custom lexicons initially so we can learn from experience.

To meet the aggregation needs and minimum privacy thresholds, the core data structure of whichever form, will need to handle batched windows of the analytics data. These won’t be able to be globally uniform timeframes. Even a single display surface may need to use different durations to support different demographic breakdowns, while preserving privacy. A closed platform can hold data granularly and just restrict by timeframes or volume upon display. But the open ecosystems need to apply limits before the data is stored for creator access. A display surface with enough traffic may be able to give view counts by the hour, but the same surface may only be able to share complex demographic breakdowns by the month.

The rest of the structure, that actually holds the analytics, I expect may end up more custom, and I’m excited to see how developers approach this. Again I’d support some standardisation, but when display surfaces end up supporting different metrics and breakdowns, the structures needed will vary too. Even when sharing similar data, the way each surface defines those metrics or demographics may differ greatly.

A few other thoughts

Analytics aggregators
Most larger apps will likely build proprietary analytics gathering, to get the most value out of this data. They can then share the aggregate metrics back to creators directly. But there is also a space for ecosystem analytics platforms, just like in the traditional open web. Smaller open social apps can use one of these analytics aggregator platforms to collect analytics data for the usage on that app, without having to implement this on their own. These can then provide views for the app owners, as well as pass it on to the creators.

Trust
This model relies on trusting the display surface to return accurate analytics data. I don’t see this as a new issue. Existing engagement and analytics, in both traditional social networks and open social networks, already relies on some trust of authenticity that can’t always be verified. In this new analytics model, at least the data is tied more closely to the display surface than some of the existing open social engagement. This allows creators to better build subsets of data they can align more trust to, rather than having a single low trust number.

Non-public engagement
Just as these analytics work for engagement that we can’t use the standard public mechanisms to provide, it also works for engagements that have typically been public to become private on some platforms. For example, a more private platform could support local liking content or local following creators exclusively for filtering content within that platform, which isn’t sent back publicly. The analytics mechanisms discussed here also allows these platforms to share aggregate data on this engagement that preserves user anonymity.

Next

I’d love to hear how you’re thinking about the challenge of open social web analytics. Are there metrics you prioritise? Or privacy concerns that you want to tackle? Let’s keep the conversation going, as that’s the best way to drive towards a great solution for the ecosystem. I’m always open to discuss this topic so let me know your perspectives.