Tuesday Tech Bytes - Adobe Analytics - Week 5 - Best Practices

[#1]

When it comes to reporting on your data, there’s more than one way to do just about everything. That’s why it’s important to have standardization across your organization. For this week, I’m going to talk about some best practices for setting up and reporting on your analytics, and why they’re important.

Documentation

Some people love it and some people hate it, but documentation is one of the most important aspects of your analytics implementation. People change roles and jobs all the time, so it’s very possible that the person (or even entire team) who set up your analytics implementation is no longer around. Once they’re gone all that’s left behind is anything they’ve written down. If a new analyst needs to understand what data is being captured, or if something looks like it’s broken, it’s vital to be able to refer to the documentation around what has been set up. There are some best practices to follow when it comes to your documentation.

First, you want to make sure that it’s in a single location. By keeping it all together it’ll be easier to see if there are any gaps or parts that need to be updated. Second, make sure that it’s updated on a regular basis. Some stuff, like the definitions of your evars, likely won’t change very often, but status updates are equally important. Did something stop capturing data for a while? Was there a traffic spike that inflated the numbers? These types of things are important to know. The best thing to do is to write it down when it happens, that way you remember all of the details. The second-best thing to do is to review your documentation on a regular basis so that you can add updates on anything that has changed. Pick a cadence and put it in your calendar. For most people, if you don’t carve out specific time to update your documentation it won’t get done. Before you know it you’ve got an SDR that is five years out of date and no one around who remembers when the implementation was set up. Make sure you avoid this type of situation; it isn’t the most fun.

Training and Onboarding

Everyone has to start somewhere. One of the best practices for bringing in new analysts is to have a specific training plan. This could be the training modules available on Experience League, training created internally at your organization, or likely a mix of the two. Every business has different needs, so including at least some organization-specific training is the best way to make sure that all of your analysts are on the same page. At my organization we’ve created an “Analytics 101” deck that every new analyst gets taken through. A member of the core analytics team spends about an hour going through the basics of web analytics, how our data is set up, and how to use workspace. Because we have this mini course, we know that everyone who comes in is getting the same training and will get exposure to our particular style of reporting. Adobe provides a lot of excellent training materials on Experience League, but it’s best to supplement that material with information about your specific set up, such as your marketing channels, your KPIs, main reports, and so on.

Even experienced analysts can learn something new. Despite using the tool every day, I feel like I learn something new at least a few times a month. Making time for on-going training is going to help keep your skills sharp and always improving. A friend once said to me “some people have four years of analytics experience, other people have one year of experience four times.” If you’re doing the same thing every day and not learning anything new, the number of years doesn’t matter, it’s the growth that matters. It’s important to carve out some time on a regular basis for training. Even if it’s just reading through the latest list of releases and testing out the new features, it can still make a world of difference for your development. And of course, make sure you put the time in your calendar, because just like documentation, if you don’t set aside time dedicated to your development, it probably won’t happen.

Component Naming

Whether you’re working on implementing props and evars or creating a bunch of custom segments, having a standard naming convention can help not only yourself, but everyone in your organization knows which variables to use. For standard components, like props, evars, and events, having a regular naming convention can make it easy to find what you need. In addition to a standard way of naming, you can also make use of the description and tags. This is especially important when it comes to props and evars. Often, we will have data that is captured in both a prop and an evar, and each is used in a different way. For example, if we have a search term that is captured as a prop and then in an evar as a merchandising evar, we can use the prop for reporting on how many searches were done for each search term, and then use the merchandising evar for our conversion analyses. Because both would have the same name, it’s best practice to include the evar/prop number in the name. So for our search terms, we might have “Search Term (c1)” for our prop and “Search Term (v1)” for our evar. One of the things that can be a bit confusing is that for evars we don’t use “e”, we use “v” instead. This is because “e” is used to identify events. If we have a search metric that goes with our search terms, it might be called “Searches (e1).”

For custom components, like custom metrics and segments, having a standard naming convention is especially important. Since generally anyone can make a new component, it’s very easy to end up with a list full of duplicates. Two reasons that this might happen are, one, components aren’t shared with everyone who needs to use them, so they need to make their own; two, the components are shared, but users can’t find them. Without a standard naming convention, searching for custom components becomes a lot more difficult. For example, if I want to report on average order value, and start searching by typing “average order” but the component is actually named “AOV”, I won’t find what I’m looking for. By agreeing on when and how to use different acronyms or including specific keywords (such as the function type, mean, average, sum, etc.) you can reduce the amount of time you spend looking for the right component. This can also prevent duplicate components from being made and reduce the need for audits to find and remove duplicates.

Visualizations

When we build dashboards for our business partners and stakeholders, there are a lot of different options we can choose. From the type of visualization to the colour scheme, to how the data is labelled, it’s possible that two people building visualizations off of the same data can end up looking completely different. Having a “style guide” for your visualizations can help all of your analysts create reports that look cohesive. Not only does having a specific style make your report look like it belongs together, but it can also actually make it easier to read. If you have a particular colour scheme that goes with your company, using it for your reporting can make the data feel more familiar for your business partners. Using a standard format for your visualizations (such as putting your metrics in a particular order) can make it easier to find the data you need at a glance. If you have different reports that have visits, cart additions, and orders, by keeping them in the same order, you’ll always know which metric you’re looking at, and it’ll be easier to compare across reports.

Conclusion

Best practices can look a bit different depending on where you are, but they all boil down to the same factors – consistency and communication. Whatever method you choose for determining your component naming convention or where you store your documentation, the important thing is to stick with the process. It’s also important to maintain open lines of communication. Having your best practices set up doesn’t mean anything if no one knows what they are. Whether you use a Teams group, a Slack channel, or any other communication platform, make sure you have a method set up to communicate important changes.

I hope that these tips for best practices can help inspire you to make your organization’s analytics the best it can be. Be sure to also check out our other Tuesday Tech Byte posts here:

Tuesday Tech Bytes - Week 4

Tuesday Tech Bytes - Week 3

Tuesday Tech Bytes - Week 2

Tuesday Tech Bytes – Week 1