Add Countly analytics #7

New Issue

2026-10-05T05:09:00+02:00

adam commented

2026-10-05 05:09:00 +02:00

The org is standardizing on use of a private instance of Countly for site analytics (rather than old blog's use of Google Analytics). @cwaring indicates that we'll need to write a manual analytics plugin to add countly integration.

The org is standardizing on use of a private instance of Countly for site analytics (rather than old blog's use of Google Analytics). @cwaring indicates that we'll need to write a manual analytics plugin to add countly integration.

adam closed this issue

2026-10-05 05:09:00 +02:00

adam commented

2026-10-05 05:09:01 +02:00

@jdiogopeixoto -- @terichadbourne and @zebateira are available to help you set this up and get you access to our Countly instance 😊 ... after that, let's discuss what specifically we want to track. Thank you!

@jdiogopeixoto -- @terichadbourne and @zebateira are available to help you set this up and get you access to our Countly instance 😊 ... after that, let's discuss what specifically we want to track. Thank you!

adam commented

2026-10-05 05:09:02 +02:00

@jdiogopeixoto correct me if I'm wrong but VuePress does not allow you access the index.html file directly so easily, so it's not the easiest way to add countly as a script and then also configure it there.

That's why we also have these plugins here: https://github.com/ipfs/ipfs-blog/tree/main/src/.vuepress/plugins ?

Countly refs:

We will discuss this more thoroughly in our call tho, just wanted to get leave some info here about the solution.

@jdiogopeixoto correct me if I'm wrong but VuePress does not allow you access the index.html file directly so easily, so it's not the easiest way to add countly as a script and then also configure it there. That's why we also have these plugins here: https://github.com/ipfs/ipfs-blog/tree/main/src/.vuepress/plugins ? Countly refs: - https://www.npmjs.com/package/countly-sdk-web - https://support.count.ly/hc/en-us/articles/360037441932-Web-analytics-JavaScript- We will discuss this more thoroughly in our call tho, just wanted to get leave some info here about the solution.

adam commented

2026-10-05 05:09:03 +02:00

Thoughts on what specific events we may want to add; would appreciate a sanity check from @terichadbourne and/or @zebateira on this ...

Countly's default data gathering should be sufficient for almost all purposes, but wondering about adding specific events for the following that we might want to use as ongoing metrics:

Clicks on nav menu items from any page, so we can compare frequency (i.e. do folks go to docs from the blog with a significantly higher frequency than other nav options?)
Clicks on social share icons from any page (individual post page, video modal); tracked per channel so we can compare frequency
Clicks on social outbound-link icons (GitHub, YouTube, Twitter, LinkedIn) from footer or from "Prefer your news a different way" section on cards page; tracked per channel so we can compare frequency
Clicks on "Submit an item" link from cards page intro text (to track this vs item submission completion)
Clicks on press kit link from cards page intro text
Clicks on "Load More" button on cards page
Clicks on "Subscribe" button in footer (to track vs successful newsletter subscriptions and check for friction in the signup process)
Clicks on other footer links, so we can compare frequency: Press, Code of conduct, Security, Protocol Labs, Terms, Privacy
Some means (apologies for being so vague here) of determining our most frequent searches and filters from the cards page; wish I could be more specific but am unsure about the best way to set this up
Some means (again, apologies) of tracking most frequently clicked tag/post-type chicklets from all pages: cards page, individual post page, video modal

Thoughts on what specific events we may want to add; would appreciate a sanity check from @terichadbourne and/or @zebateira on this ... Countly's default data gathering should be sufficient for almost all purposes, but wondering about adding specific events for the following that we might want to use as ongoing metrics: - [x] Clicks on nav menu items from _any_ page, so we can compare frequency (i.e. do folks go to docs from the blog with a significantly higher frequency than other nav options?) - [x] Clicks on social _share_ icons from _any_ page (individual post page, video modal); tracked per channel so we can compare frequency - [x] Clicks on social _outbound-link_ icons (GitHub, YouTube, Twitter, LinkedIn) from footer or from "Prefer your news a different way" section on cards page; tracked per channel so we can compare frequency - [x] Clicks on "Submit an item" link from cards page intro text (to track this vs item submission completion) - [x] Clicks on press kit link from cards page intro text - [x] Clicks on "Load More" button on cards page - [x] Clicks on "Subscribe" button in footer (to track vs successful newsletter subscriptions and check for friction in the signup process) - [x] Clicks on other footer links, so we can compare frequency: Press, Code of conduct, Security, Protocol Labs, Terms, Privacy - [x] Some means (apologies for being so vague here) of determining our most frequent searches and filters from the cards page; wish I could be more specific but am unsure about the best way to set this up - [x] Some means (again, apologies) of tracking most frequently clicked tag/post-type chicklets from all pages: cards page, individual post page, video modal

adam commented

2026-10-05 05:09:04 +02:00

Will continue to ponder this list, but I expect that the answers to what needs custom tracking will depend on how the new IPFS blog and the re-platformed IPFS website en up interfacing with each other. If there's any chance they'll end up in the same site (despite the implications of the blog needing more frequent updates by a wider collection of folks that the website does) then a few of these things might end up taking advantage of built-in analytics features like funnels.

Some things you've listed, like footer link clicks, come built in, but based on what @zebateira and I have learned about the number of data points stored for each event (not number of segments but number of potential values for the segment, like every link that ever exists on the blog), or based on the fact that they appear on multiple pages, you may indeed want to set up custom tracking events regardless that are structured in a way that's easier to report on within Countly.

Will continue to ponder this list, but I expect that the answers to what needs custom tracking will depend on how the new IPFS blog and the re-platformed IPFS website en up interfacing with each other. If there's any chance they'll end up in the same site (despite the implications of the blog needing more frequent updates by a wider collection of folks that the website does) then a few of these things might end up taking advantage of built-in analytics features like funnels. Some things you've listed, like footer link clicks, come built in, but based on what @zebateira and I have learned about the number of data points stored for each event (not number of segments but number of potential values for the segment, like every link that ever exists on the blog), or based on the fact that they appear on multiple pages, you may indeed want to set up custom tracking events regardless that are structured in a way that's easier to report on within Countly.

adam commented

2026-10-05 05:09:04 +02:00

@zebateira @terichadbourne @jdiogopeixoto - adding one other item that needs to be tracked: Per https://github.com/ipfs/blog/issues/349, can we please count requests for the RSS feed at index.xml so we can see if RSS subscriptions/queries change over time? Thank you! 🙏

@zebateira @terichadbourne @jdiogopeixoto - adding one other item that needs to be tracked: Per https://github.com/ipfs/blog/issues/349, can we please count requests for the RSS feed at `index.xml` so we can see if RSS subscriptions/queries change over time? Thank you! 🙏

adam commented

2026-10-05 05:09:05 +02:00

@zebateira @terichadbourne @jdiogopeixoto - adding one other item that needs to be tracked: Per ipfs/blog#349, can we please count requests for the RSS feed at index.xml so we can see if RSS subscriptions/queries change over time? Thank you! 🙏

At first glance I don't see how we can track this to countly easily, considering the access to /index.xml does not open the vue app, and so, countly is not loaded for use.

I had the idea of adding a client-side proxy redirect with the only purpose of tracking access to the rss feed link,
but the problem with a redirect is that I'm not sure if rss feed readers follow these redirects, so we would need to test this.
And even if it works, users could click the link and be redirected to the /index.xml file and then copy the xml file link instead of the initial redirect link which would not allow us to track the access.

Another alternative would be to intercept the /index.xml (we would need to ask the fleek team for this to add this custom config) and redirect to a server endpoint that would use the countly js sdk and send the tracking event to countly before responding with the index.xml file (this could be done with lambda functions and fleek doesn't have them yet, but netlify does).

Do you have other ideas for this @jdiogopeixoto @lidel ?

> @zebateira @terichadbourne @jdiogopeixoto - adding one other item that needs to be tracked: Per ipfs/blog#349, can we please count requests for the RSS feed at index.xml so we can see if RSS subscriptions/queries change over time? Thank you! 🙏 At first glance I don't see how we can track this to countly easily, considering the access to `/index.xml` does not open the vue app, and so, countly is not loaded for use. I had the idea of adding a client-side proxy redirect with the only purpose of tracking access to the rss feed link, but the problem with a redirect is that I'm not sure if rss feed readers follow these redirects, so we would need to test this. And even if it works, users could click the link and be redirected to the `/index.xml` file and then copy the xml file link instead of the initial redirect link which would not allow us to track the access. Another alternative would be to intercept the `/index.xml` (we would need to ask the fleek team for this to add this custom config) and redirect to a server endpoint that would use the countly js sdk and send the tracking event to countly before responding with the `index.xml` file (this could be done with lambda functions and fleek doesn't have them yet, but netlify does). Do you have other ideas for this @jdiogopeixoto @lidel ?

adam commented

2026-10-05 05:09:05 +02:00

@zebateira @terichadbourne @jdiogopeixoto -- your thoughts on the following?

We are tracking outbound social shares through clicks on our share links, but it would also be nice to track inbound traffic that comes from those social shares. Would the best way to do this be to append a referrer to the URL (e.g. ipfsBlogShare) that gets passed through to the Twitter/FB share widget, and then use Countly to track page loads with that referrer in it?

If that's the case, @jdiogopeixoto, would you mind setting that up in the blog code so I can add it on the Countly dashboard side? 🙏

@zebateira @terichadbourne @jdiogopeixoto -- your thoughts on the following? We are tracking outbound social shares through clicks on our share links, but it would also be nice to track _inbound_ traffic that comes from those social shares. Would the best way to do this be to append a referrer to the URL (e.g. `ipfsBlogShare`) that gets passed through to the Twitter/FB share widget, and then use Countly to track page loads with that referrer in it? If that's the case, @jdiogopeixoto, would you mind setting that up in the blog code so I can add it on the Countly dashboard side? :pray:

adam commented

2026-10-05 05:09:06 +02:00

We are tracking outbound social shares through clicks on our share links, but it would also be nice to track inbound traffic that comes from those social shares. Would the best way to do this be to append a referrer to the URL (e.g. ipfsBlogShare) that gets passed through to the Twitter/FB share widget, and then use Countly to track page loads with that referrer in it?

Yes, that's a good way to track that 👍

We haven't explored this at ProtoSchool, but there are campaigns on Countly:
https://support.count.ly/hc/en-us/articles/360037639331-Attribution-Campaign-Types

Considering we have the countly.ipfs.io subdomain setup, the link will not be so weird for the users.
We can always ask the Countly team about this feature or what is the best way to track this (they might present another feature they have that would better fit this purpose).

> We are tracking outbound social shares through clicks on our share links, but it would also be nice to track inbound traffic that comes from those social shares. Would the best way to do this be to append a referrer to the URL (e.g. ipfsBlogShare) that gets passed through to the Twitter/FB share widget, and then use Countly to track page loads with that referrer in it? Yes, that's a good way to track that 👍 We haven't explored this at ProtoSchool, but there are campaigns on Countly: https://support.count.ly/hc/en-us/articles/360037639331-Attribution-Campaign-Types Considering we have the `countly.ipfs.io` subdomain setup, the link will not be so weird for the users. We can always ask the Countly team about this feature or what is the best way to track this (they might present another feature they have that would better fit this purpose).

adam commented

2026-10-05 05:09:07 +02:00

Closing this with the acknowledgement that we still need to duplicate the staging dashboard for prod once the DNS is re-pointed to blog.ipfs.io. That work is captured in https://github.com/ipfs/ipfs-blog/issues/22.

Closing this with the acknowledgement that we still need to duplicate the staging dashboard for prod once the DNS is re-pointed to blog.ipfs.io. That work is captured in https://github.com/ipfs/ipfs-blog/issues/22.

adam commented

2026-10-05 05:09:07 +02:00

Didn't know where to put this, so here it goes.
I've added tracking for 404s by adding the custom event 404NotFound

This way we can track that event's segment referrer to see where broken 404 links are being referenced from (the data you see above is just testing data, but that's how roughly it will work).

Done here #106

Didn't know where to put this, so here it goes. I've added tracking for 404s by adding the custom event 404NotFound <img width="1088" alt="image" src="https://user-images.githubusercontent.com/2353186/114011573-4744be00-985d-11eb-991c-25172e584ceb.png"> This way we can track that event's segment `referrer` to see where broken 404 links are being referenced from (the data you see above is just testing data, but that's how roughly it will work). Done here #106

adam commented

2026-10-05 05:09:08 +02:00

Thanks @zebateira - I'll get that in the Countly dashboard for prod.

Thanks @zebateira - I'll get that in the Countly dashboard for prod.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/ipfs-blog#7