The analytics data we tracked so far was pretty minimalistic. While we have added some UTM tags in the past, the usage of them was inconsistent to say the least.
So, when we set out to improve the way we display feature hints and generally experiment a bit more with other things from inside the plugin, I wanted to make sure that we also get some usable data about those links.
If you don’t know already what UTM parameters are, you can find an introduction in Google’s own Analytics Help Center to get you started.
Setting some Goals
First things first: I googled about UTM best practices and looked at what other plugins are doing and as with many things, there are a lot of different ways how you can go about this, none necessarily more correct than the other.
But I needed to decide what’s best for us, so I did what I often do in such situations: I wrote down a list of the most important questions that I want answered.
- Do people click on our pro metabox “banner” from inside our plugin?
- Do people click on the inline feature hints, that we display in the editor?
- Do people click on some of those feature hints more than others?
- Do people click on our “banners” that we placed inside our settings pages? And if, which?
- Do people click more on links from some screens in the plugin than from others (settings VS editor screens for example)
With these goals in mind, I started looking for the technical implementation.
Next: Use a Link shortener
In the past, when we added UTM parameters to links, we hardcoded them into our plugin code, readme files or wherever else we put them. While this kind of worked, it made every change dependent on us pushing a new version out and then also wait until people upgraded to that new version. This can take some time (or in some cases never happen) and makes the data unreliable.
The solution to this is using a link shortener, where we can define shortlinks like go.picu.io/some-link
which then get redirected to the proper URL including all of the needed UTM tags. These shortlinks are then place wherever we need a link to our website. We decided to use the open source and self-hosted “YOURLS” but you could also use a service like bitly and get the same result.
Now, if we want to change anything in regards to those UTM tags in the future, maybe rename a tag or even add a new one, we can simply update the target URLs in our shortener and those changes will be live immediately. No need to push any code or wait for any upgrades to happen.
UTM Strategy
After I wrote some of my initial ideas down, a good friend – who happens to be a Digital Analytics Pro and eats this stuff for breakfast – sat down with me and helped me a lot to unwhirl my own thoughts and get this started. Thanks Boris!
As said above, there are various ways to structure your UTM tags, and those can go from pretty simplistic all the way up to very, very complicated setups. Our old setup was too minimalistic, but I also don’t wan’t to overcomplicate things, so we needed to find something in the middle.
As a baseline, here’s what we did in the past, with our old “setup”:
UTM parameter | Description |
---|---|
utm_source | picu_plugin – for all in-plugin links wordpress.org – for links coming from the plugin repository (I think these are added by default by wp.org?) |
utm_medium | pro_hints – all hints we placed inside the plugin (things like “Did you know you could do X and Y with picu Pro?”) pro_metabox – our main “banner” that we show in the metabox of the wp editor screens |
And that was about it. While this gave us some data, there was a lot to be desired as well.
For example, we could see if pro_hints where clicked, but could not differentiate between them.
So, without further ado, here’s what we ended up with, at least to begin with:
UTM parameter | Description |
---|---|
utm_source | Where is this link coming from, at this point we’ll mostly have: picu_plugin – for all in-plugin links wordpress.org – for links coming from the plugin repository email – our own newsletter |
utm_medium | We use this for the type of link. This will certainly evolve, but so far we use: feature_hints – all feature hints inside the plugin settings_banner – banners on the picu settings page for pro features settings_docs – help links from settings to our documentation pro_metabox – our main “banner” that we show in the metabox of the wp editor screens |
utm_campaign | A descriptive title for the campaign, for easier handling this will often be the same as the slug of the shortlink, for example: more-control – is used as the campaign for the shortlink go.picu.io/more-control |
utm_term | The screen this link was placed on in the plugin, like: screen_edit-collection – edit screen of our collections screen_picu-settings – our picu settings screen |
utm_content | – (not used so far, but might be for things like an A/B test or if we want to differentiate between a link on an image and one on a text etc.) |
This new structure has been live for two days only, so it’s too early to tell if it works as I hope or what adjustments we need to make, but I’m optimistic and look forward to getting some more insights.
If you use a similar structure yourself (or even a completely different one), or have anything else to add, please let me know!