Tracking redirects on Cloudflare with Google Analytics
Tags: webdev, cloudcomputing, analytics, edgecomputing
Published: 2024-01-28 11:59:32

I recently came across this interesting problem of wanting to track URL redirects with Google Analytics on Cloudflare and it got me spending some time into investigating how things work and a potential solution.

Before I explain my solution, let me provide some context on the problem. I am working on a side project that requires directly invoking a 3rd party native mobile application when the user visits a certain URL on my domain. As the final touch point for the user is a native app, I don't have much control over tracking the user action for opening an app.

A typical solution for this would be to introduce an interstitial page where you would load all of your tracking and then redirect the user. As the end result is a mobile app and to avoid loading another page in between, keeping the number of steps and intermediaries to a minimum will keep the latency as low as possible.

As my domain is currently setup with Cloudflare, I started exploring options for computing at the edge as that provides the lowest latency physically possible. Cloudflare has an offering called Workers which is essentially computing at the edge and it can hook into handling incoming requests for one or more routes through wildcards. So if I can capture the requests, extract necessary metadata and send a request to Google Analytics, then I should be able to have analytics on my URLs with low latency.

The first step for the process is to create a Cloudflare worker. That was pretty straightforward based on the documentation that gives you a good scaffolding for either plain JavaScript or to use Typescript, I went with the latter to have type safety and to detect any potential issues early on. Using the wrangler CLI, I was able to build and deploy the project directly from my machine with very little hassle. I directly added environment variables in the dashboard and updated the deploy command to skip deleting these vars. The dashboard also gives you an option to encrypt secrets such as passwords and API secrets.

The next step was to integrate with the Google Analytics API. After setting up a new property on Google Analytics 4, I obtained an API secret for the Measurement Protocol. As per docs, this API supports server to server invocation and is used for enriching existing events sent directly from the UI. In my case, there is no web UI and so I will solely be using this for sending event data.

Creating the event payload was tougher than I thought. It wasn't easy to find the right combination of attributes to get the events to show up on the realtime report view in Google Analytics. After going over multiple posts on StackOverflow and trial-n-error, I was able to get the events to show up with the attribute data that I sent.

User location information is important to understand where your users are from and how your marketing campaigns are performing so that you can make a call on how to structure your content marketing strategy. Sending location information: city and country directly to Google Analytics did not show up on the default user demographics dashboard which was frustrating but after some investigation into the documentation, I found that sending geo location information for users is not accepted by the Measurement Protocol for now.

The workaround for viewing User location data is straightforward. Attach the location information for each event and then create a custom dashboard where this information shows up in with aggregates on timeframe such as 6 hours, 1 day, 3 days etc.

If you have come across this problem before and would like to implement the same solution as described above, you can use this [Github repository ](https://github.com/allentv/cloudflare-worker-ga4) to deploy the changes. Just update the environment variables and deploy using wrangler. Good luck!