As we get closer to having permissioned spaces, I’ve seen lots of great discussions around communities. So I thought I’d kick off another discussion topic for another permissioned space usage - analytics.
I’ve been doing some thinking on the topic: Analytics on the Open Social Web • RocheBit . But as I don’t actually have a live application with users yet, my investigation into this has been somewhat academic so far. Still, this topic is a real interest of mine, as I think creator-owned analytics will greatly help the ecosystem, and I’d love to hear how others in the ecosystem are thinking about analytics.
So to kick things off, I’ll ask two questions:
1 - what metrics would you want to provide back to creators from your apps?
2 - would you view writing to a permissioned space that doesn’t exist yet (e.g, ats://creator.did/community.lexicon.analytics.space/self) an acceptable use of the architecture, or a bit of an anti-pattern?
I think the question of “what metrics would we want to provide?” is pretty tangled up in the core assumptions at the top of your article on analytics. This moved me to write a more full response: On Communication and Engagement
TL:DR; analytics are research data to answer questions in regard to transactional marketing. Being clear about how this is a different use case than social communication is extremely important, and will guide the development of the core question which is “Is what I am doing working towards my goal?”
We have been discussing this lately and thinking along pretty similar lines. The idea that apps send analytics to a creator’s PDS seems pretty cool, since it really should be the creator’s data to own. I haven’t evaluated the privacy/anonymity aspects deeply, but I’m fairly sure that stats like view counts can be sufficiently anonymized to be a non-issue.
A few thoughts on the implementation
I’d probably suggest some simple analytics-oriented APIs which could in turn write to a permissioned space or something else. Just something like “uploadAnalytics” ? And the caller auths with the same mechanism as atproto-proxy so it’s clear which app is sending it.
The strength of that is also the weakness - it enables apps to send analytics without any kind of arrangement being set up with the creator. This could help people get a wide view of things, but it runs into a spam & lies problem that the PDS would need to address, as shady apps would be incentivized to send fake positive numbers to catch the creator’s attention
I hadn’t really considered a new API for this on the PDS, so I’ll have to think through that option further. I need to make sure I’m not being biased just because I’m a bit in love with the proposed permissioned space architecture.
I think the spaces do offer a reduced spam vector, which is an interesting benefit, as you’re only notifying the creators PDS, rather than trying to send data through to them.
The trust model for apps, that may lie and inflate numbers, doesn’t really change. But it does offer an easy way to define different datasets that are more/less trusted just by the writer DID (which I’m expecting is a DID for that app, not a users DID). I expect dedicated analytics AppViews to view and pull insights from this data will quickly start to offer views that account for varying trust levels.
There is a trust piece that the spaces do provide - as it provides some credibility to creators who are sharing metrics to 3rd parties, especially for business engagement where creators have a clear incentive to inflate their metrics. And that doesn’t have to be giving those 3rd parties direct space access, e.g, a trusted analytics AppView can verify the authoring of the data.
That’s not saying we can’t offer some of those benefits via the API, depending on implementation.
@nikolas.ws - love it, thanks for the rebuttal
I think I was assuming a broader definition of engagement, as I thought your examples like radio were great examples where there is a lot of effort to measure engagement and reach. But I do fully expect that the answer to “what metrics would we want to provide?” to some people will be “none”. Being an open ecosystem, I expect there will be apps that will take this route, which users and creators (although creator choice is a bigger topic) can choose which best suite their needs.
@gui.do - perhaps, if I manage to secure some more of that mythical free time
One interesting element about using permission spaces is, all writers will be authorized to read too. So if we use that directly then all of the participating apps will be able to read the creator’s analytics from the other apps.
Not sure if I think that’s a pro or a con. Kind of nice, maybe, for the worksharing aspect of it?
I had had a thread about publishing email subscriber counts to a Standard Site publication. The atproto subscribers are public, but the email ones are not.
We don’t want the pub owner to artificially inflate. And note all publishers will want to share this.
Can the appview “sign” a subscriber count in order to verify it?
This is very app specific, especially since right now the apps are keeping all this info in a private, off-protocol database.
I thought this is at least adjacent to analytics, and might be a simple thing to prototype early?
Yeah I think email subscriber count is a great analytics metric.
Makes sense that this would be a requirement, for at least some verificiation.
Does it? One of the parts I liked was that I thought the write and read were so separate. That anyone could “write” to any space, whether or not they had read access, whether or not the space even existed yet. And that “writing” to a space doesn’t mean it will ever be read from a space. I certainly wasn’t arguing that the analytics should be public to all other AppViews. I was expecting it was privately provided to the creator, who could then control who could read from the space, and what should be read from the space.
This is something I’ve been focusing on for Livtet (still in stealth, sorry!) in the case of authors who want to track engagement to their author profiles and what have you.
A marketing representative at a publishing company I’m working with made good points about what kinds of information they’d want and I decided with the following: split the analytics problem cleanly between two questions that often get smashed together: “am I being heard?” and “is this working?” The first is social; it’s about knowing someone started your book or joined a giveaway (giveaways help justify more book sales for indie authors - similar to Bandcamp Friday). The second is transactional; conversion rates and which promotion drove the most book club joins. Livtet’s approach will own the first by putting it on the author’s PDS via permissioned spaces (eventually), and the second will live in a hosted API for now with firehose ingestion for public signals like shares and replies (effectively an analytics appview). Reader-level tracking defaults to opt-out; we aggregate at the source and threshold small counts to prevent deanonymization.
Handily the permissioned data proposal does allow you to do writes without reads with a custom space host ( even if maybe not built into the simple space hosting ).
Granting read without write needs to be done at the app level, i.e. having the app ignore writes or just not go and lookup the writes for certain people in the first place, since anybody will always be allowed to write anything to their PDS.
