[Music] [Christel Guidon] Hi, everybody. I'm Christel Guidon. I'll be conducting the first part of the session, and then Meghan Powers here with a much cooler name will be doing the second part. Quick show of hand, how many of you guys are admins or have admin like functions? I got the right audience. Cool.
Just remember that all slides are available on demand after Summit. I do have some reference slides in here that we won't go over in detail, so no need to take pictures. Everything will be available for you.
Quick intro about me and my company. So I'm originally from Grenoble, France, heart of the Alps, but I've been in the California Bay Area for about 20 years, and I've been an Adobe Analytics enthusiast for most of those. I'm married with two kids who take a lot of my time, which is one of the reasons for these tips. And I love sports, and I love record collecting.
My company is GEN Digital. You may not be familiar with it, but it's an umbrella brand for seven well-known trusted cybersecurity brands, including Norton, LifeLock, Avast, AVG, Ccleaner, Reputation Defender, and Avira.
I've been there almost-- No, more than 16 years. So I've seen a lot in 16 years, really a lot. And over there, I'm a one-person team for anything and everything Adobe Analytics. So implementation, reporting, administration, documentation, user management, you name it.
And we have nearly 1,000 users in the platform, so I have zero, absolutely 0% chance that somebody doesn't need me every single day...
Which is why I came up with these four tips for overworked admins like myself and like a lot of you.
So one thing to note is I'm a very operational pragmatic person. These are not rock star ideas. That session is at 1 P.M. I highly recommend that you go, but this is not it.
My goal here is to give you quick, fast, easy ways for you to better manage your workload and just save time and frustration. Maybe a lot of you have built similar things already or I don't know, you've done similar things for your companies or you've had these ideas, but from talking to a lot of people, I feel like it's not the case.
If you are not an admin, please don't be afraid. You can just take these tips to your admin, or you can build these for your business units, and other business units will follow.
So with that, let's get into the first step, which is build an FAQ Dashboard, my absolute favorite tip.
So a lot of times, I get the same question from different users again and again and again. And like I said, I've been at my company over 16 years, so this really just drives me absolutely crazy. And what happens is most of the time, I'm going to dig through my emails and be like, "Where did I write this? I did this two weeks ago. Who did I send it to?" And I end up being like, "Am I going to spend more time looking for this in Outlook?" Or "Is it just going to be faster to write it from scratch?" I also get people like Debbie here.
She likes to ask me the same question every two weeks. She'll ask me, and then she'll ask me two weeks later, and then she'll ask me two weeks later, and she'll do that until the end of time.
Stop answering these people. Build an FAQ dashboard.
So just put your answer directly into Workspace nice and clean, detailed once and for all.
Then next time you get that question, right click, get visualization link.
You will get this nice little popup with a cute vanity URL. Hit Copy. Boom. Done. No more long answers. No more typing forever. No more disparities in what you're saying. No more wasting your time and energy.
So how do you build an FAQ dashboard? So simple. Just use text visualizations. Type out your answer. Give the FAQ a title that makes sense. Nice, short question formats is what I like. Collapse them all. Put the most popular ones at the top. Share that FAQ dashboard with the whole company. Very important to note is when you send one of these cue to vanity URLs, it'll bring users not only to the FAQ dashboard, but it will, by default, expand the FAQ in question. So people know exactly which FAQ you're sending them to even if they're all collapsed. When you send them there, they know which one you're referring them to. You don't have to use text visualizations. You can use Freeform tables, Venn diagrams, flowcharts, whatever you want. Just right click at the top, edit description, put your content in there, and then collapse it.
So just some tips. Every time you're writing out something and you're like, "Hey, I answered this two weeks ago. When's the next time I'm going to have to type this out?" Or you feel like, "Hey, I'm going to have to type this out again in three weeks." Or every time you type out something long and you feel it's beneficial to the company, just stop and put it in an FAQ instead. Just build it out little by little. You don't have to do it all at once. I think I took two, three months to build mine. And then when I had enough content and I felt like it was enough, I shared it with the whole company. I do build on it continuously, and I maintain answers as things change so people trust it.
So why, as an admin, you should build an FAQ dashboard now? Save time, save frustration. That's my favorite thing. Over time, you're training users to go to FAQ dashboard instead of reaching out to you or just to get their answers faster.
I'm trying to build trust in the platform that it has everything that people need just directly built into it. It's simple, but it's a free and easy way for you to organize your knowledge directly in Adobe Analytics or CJA. In my experience, when you send people to confluence, spreadsheets, word docs, etcetera, they either, A, don't go, or, B, they bookmark it and then they don't go. So if you just give them less steps, it's just more likely that they'll actually go there.
Having these FAQs also allows you to link them in other dashboards, other reports. You can be like, "Hey, for more info, see this FAQ," or also link your FAQs together. "For related info, also see this FAQ." So very simple idea, but it has genuinely saved me a ton of time and frustration, and I use it every day.
Quick spoiler alert for my three other tips, they're all on the same theme.
So with that, let's go to Build Overview dashboards.
So what is an Overview dashboard? Why do you need these? A lot of times people look at Adobe Analytics for CJA and they're like, "What's in this thing? How is the data organized? How is the business split?" New users are often super overwhelmed. They see this huge list of reports. They don't know where to start. They don't know what to do. Executives are always like, "Hey, why do we have this tool? How much is Adobe Analytics costing us?" And as an admin, I'm always like, "How am I supposed to have the bandwidth to help so many users?" So Overview dashboards can help you. You can show an overview of the business and how it splits. They allow you to show the right data to the right people, and they let people dive into each property, like each piece of your business. As an admin, save time, save frustration, let Overview dashboards help you out.
This is just a quick reference slide on using Property tags. I have an experience leak article on there. This is just my most loved dimension that I use every hour. And it's just the way that I split out my domains, subdomains, mobile apps, all that. So just a slide for you after Summit.
What types of Overview dashboards should you create? So the goal is to show a basic breakdown of your business and understand each area, each piece of your business. So think brands, your sites, your subdomains, your mobile apps, all that. Do not go too granular. Don't start looking at localization, etcetera, etcetera. Do start with a basic Master Overview dashboard that shows all the pieces of your business together. This is especially important for executives. But then based on that, dive into each Individual Overview dashboard. So think, all your brands, all your domains, all your subdomains that have a specific focus. By that, I mean cart, support, account, login, mobile apps, channels, like paid search, affiliates, SEO, or by tool if your company does a lot of that, like video, feedback tool, chat.
How to get started? Again, just start. Build them out little by little. You don't have to do everything all at once. Do start with that Master Overview dashboard, and then from there create a clickable list of Overview dashboards. I'm going to get back to that in a minute. Absolutely save time and cheat. So if I build, like I spent a lot of time building an Overview dashboard for one brand, and I have a brand that's even somewhat similar, instead of starting from scratch, I do project, save as, I'd rename the thing. Right? And then I just tweak it for that brand. So you don't have to recreate the wheel every time, do cheat.
Also, you can copy whole visualizations from one overview to another. If you've built a complex table or a complex chart, whatever, just right click, copy visualization, go to your new dashboard, paste visualization.
Do share these with the whole company. You may think like, "Hey, support people don't care about mobile apps and vice versa." But it's really important for you to show your whole business and to show how these pieces are altogether. You'd be surprised how business people have no idea how big or small their piece of the business is. So have analytics be the tool that ties everything together.
When you share, give people edit-copy access only. That way, they can't mess up the original. Only you get to pull that one off. But they can create their own copies. So project, save as, and then they can build a version just for France or a paid search version. This also lets Debbie take your project, save as, put her name on it, and pretend that she's so cool. Just let her do it. It's fine. Just let her do it.
It also lets your users take whole tables, visualizations, and just do copy and put them in their reports. So you're also saving your users a lot of time.
Do tag these as Overview dashboards, use company folders, whatever your system is. Just make sure they're easily findable by everyone. And do link them altogether if you don't know how. It's in blue on the slide.
So here's that clickable list of Overview dashboards I mentioned. Real simple. It's just a text visualization, and I have vanity share links to create this list of all my Overview dashboards. And by having this, I let users dive into each piece of the business without needing me. So I post this thing everywhere, FAQ dashboard, news and announcements dashboard, all over the place. As you can see my example is on the right. At GEN, I have a very complex ecosystem in one report suite. So I have my seven brands. They all have different mobile apps, this, that. For me, it's really critical that I can show all the pieces of the business together.
Some tips for creating your Overview dashboards. Do keep them real simple and basic at the top. Use summary numbers, simple trends. I like to think, would my mom understand this? Real simple. Then you dig into specifics, for that property after those basics. Do make the data easy to consume. By that, add context to your stuff. So right click, edit description, is one of my favorite things.
Explain the user flow. Explain, illustrate the table. Right? Illustrate the data. Also, I love to hide the underlying data. So if I have a complex table and I'm building a visualization, I hide the datas, the table, so that my Overview dashboard isn't overwhelming and I'm not frustrating my users.
Do tailor each Overview dashboard for the specific team in question. So for example, the support team, they probably don't care about revenue creation. They care about keeping escalation costs down. Are people using internal search? Are they reading our knowledge base articles? Mobile team, they care about crashes, upgrades, launches per user, etcetera. So just different teams have different goals, cater to those. And then when you create an Overview dashboard, keep that thing well-maintained and well-updated so people trust it, like you're trying to get people to trust your Overview dashboards.
Do not make them overwhelming. Resist the urge to put 55,000 reports in your Overview dashboards. Nobody wants to see that. If Debbie wants a detail that only she cares about, the answer is no. No, Debbie. No. If you have very specific flow goal dashboards that are specific to something that's cool. Just create cool reports for you to check out list, but be critical of what is an Overview dashboard and what is not.
Here's a very simple example of my Master Overview dashboard. This is just the top. My goal is just to show you how basic it is. Right? So anybody can understand this. It's all fake data. I got my seven brands at the top, traffic, conversions, and then I have my clickable list of Overview dashboards. Below this, I dig into more specifics, but as you can see you can look at the brands and be like, "I want to learn more about this brand," and click on the related brand on the right.
This is an example of one of my Individual Overview dashboards. So real simple at the top, and then I dig into what is special to that property, what countries people coming from, what products are being sold, etcetera, etcetera.
So if you're lacking inspiration or you just need ideas for your Overview dashboards, I have three reference slides here. This is for after Summit just for you to get ideas to build your own Master Overview dashboard, Individual Overview dashboards, more specific Overview dashboards.
So why, as an admin, you should do these, build these now after Summit? One is build trust in the platform. That's really important. You're eliminating that initial learning curve that comes with Adobe Analytics or CJA. There's no need for all of your users to be Analytics experts. They just need know how to log in and click twice. And they get a bunch of really cool info, and you can show off how cool Adobe Analytics or CJA is and all the powerful stuff that the platform can do. You're building trust that the data is well-organized. The tool is well-managed. That's the goal. As an admin, you save time, save frustration. These do take some work upfront, but they answer 80% of the questions that I get as an admin. So they really help me out. I'm giving users an easy way to just dive into properties without any hand holding, so without needing me. That's the goal. And also, I get a lot of vague questions and requirements, as I'm sure a lot of you do. And I'm able to redirect those here. So before I spend an hour with Debbie figuring out what she wants, I just send her the Overview dashboard and tell her, "Hey, be more specific." So tip number three is build a news and announcements dashboard. I don't know how you guys are getting your news out to your users about Adobe Analytics CJA. Maybe you're sending a newsletter. I don't know. I tried that. It never worked very well. So if yours works, that's great. But if you're sick of creating this thing and wondering, "Hey, does anybody read it?" You can build a news and announcements dashboard instead, or you can do both.
So basically, my point is that I'm just keeping everything within Workspace. I keep everything directly in Workspace, and I use that to keep everyone informed. So anytime I have a new site, a new app, or I have a new feature, a new release, "Hey, we just started tracking payment method. Check it out here." Or anytime Adobe puts out a cool feature, I, as the admin, know this. I don't expect my users to keep up-to-date with everything Adobe is doing, but I like to communicate to them so that they can use the latest features.
Any large code updates I do, new Overview dashboards I create, all that.
I also incorporate my known bugs and changes log in here. So you can have a separate dashboard for this. I just stick mine at the bottom of my news and Overview dashboards. But basically, I used to have an Excel file, and nobody ever read that thing, and I barely did. It was a pain to maintain. And in Workspace, I just have my bugs in chronological order. And when somebody tells me, "Hey, why did traffic tank last week?" I just go, "Hey, check out my bug log." So how to build this thing? It's so easy. Just text visualizations, bullet points, have a report per year. I keep my previous years in there and then just collapse them. I have a specific format, and I share it with the whole company. So anytime there's an update, it floats up to the top of their Workspace list, and I'm trying to train people to just look at it.
Again, just start now after Summit and before you know it, it'll be quarter end, and you'll have a ton of stuff in there. Work in whatever historical data you have, and then share with the whole company when you feel like there's enough. When you start, though, do keep it well-maintained and updated, and keep everything real short and simple. So do not try to get credit for updating app measurement version, nobody cares. Absolutely nobody cares. Do not do a full review of a bug in this thing. Just real nice, short and simple.
And then link all your other content in there. So put your clickable list of Overview dashboards in your news and announcements dashboard, put your cool reports to checkout list, right click at the top edit description. That's my favorite thing. Put all your info in there.
So I warned you, mine is real simple, real ugly, but it does the job. Right? So I can just use this thing. It doesn't have to be some crazy pretty thing.
So why, as an admin, you should build a news and announcements dashboard now is save time, save frustration. It's my favorite thing. Over time, you're training users to keep an eye on this, and you're building trust in the platform. So it's just a free and easy way for you to organize everything directly in Workspace.
My last tip is build an admin monitor dashboard. Same operational stuff with me, there's really no surprises.
I just use this to keep track of all my reoccurring issues in a single place. It's just for me, the underappreciated admin, and I don't share it with Debbie. I just use alerts for each issue. And every time I get an alert, I just go to that section and I can check out the details of the issue. So the goal is that I'm not starting from scratch every time I get an alert to figure out what's going on.
Very, very simple example. I get an alert that one of my unspecified values is going up, and then I just go to my monitor dashboard and I can see, hey, my classifications are out of whack.
So some examples of things I keep track of, server call usage, visitor ID not being properly set, my property tag not being properly set, user agents and bots, stuff I'm decommissioning, are my classifications working, those pesky unspecified values. Distinct count, I really love that one. I have that for all my dimensions. So it tells me if all of a sudden I had 50 items in one dimension, and the next day I have 50,000. I know some developers started sending GUID in there or something like that, so that's very helpful.
I also have checklists for all my repeat tasks in there. So every time I'm setting up a new site, mobile app, variables remember to do this update interface, update SDR, etcetera, etcetera.
I have my QA checklist in there when I'm checking a cart, here's what I check, and even copy paste for emails, new user accounts or whatever. So just things for me to make less mistakes.
Here's some of the stuff that I track. So it's just all my panels collapsed. So just an example of some of the stuff I track.
You know the song. Why should you do this? Save time, save frustration, monitor your stuff faster, don't recreate the wheel every time. And again, it's just free and easy. You can all do it. You don't need anything.
So that's it for me. Do remember that all slides and references are available on demand after Summit. And these tips are real simple, but they have genuinely saved me a ton of time, and I hope that you can go home after Summit and save time as well. So the session's not over yet. Get ready. Get excited for Meghan.
[Man] Thank you, Christel. That was amazing. Thank you for helping us all defeat Debbies at our company. And if there's any Debbies in the audience, I am so sorry. Go to the back. Kelsey and Sean will give you money or something to make up for it. So sorry. All right.
Who is ready to learn about comprehensive tagging strategy? Okay. Just a couple nerds here. That's fine. That was expected. All right. Next up, we have Meghan Powers from CarMax. Will you please join me in welcoming Meghan up to the stage? [Meghan Powers] Alrighty. Who went to Bash last night? Heck, yeah. It was awesome.
The last time I spoke at Summit was also the Thursday morning after Bash. I think I need to talk to Justin about getting a more favorable time slot.
So Christel just did an awesome job talking through, how to be more efficient and tips and tricks for Workspace. We're going to take a little step back and talk about how we get the data there in the first place with tagging requirements. So a little bit about myself, I'm a three-time Adobe Champ and I'm on Experience League Community as an advisor.
I wasn't planning on mentioning this. I went to William and Mary, and we are the second oldest college in the US, but one of the few that have never been to the NCAA tournament, but our women are playing tonight for the first time. Go Tribe. Yep. Very excited about that. I love playing lots of different sports, lots of different boarding activities. I've been at CarMax for a little over nine years now. I lead a team called Digital Data Strategy there.
We are responsible for capturing every piece of digital data on every CarMax digital property, so carmax.com, the apps, our auction sites, many internal facing sites, etcetera. We also capture all of our third party tags. Our team is half analyst, half developers. We're a centralized team, and a little shameless plug for that blog post I wrote a couple years ago about forming a centralized tagging team if you're interested in that. But what that means is we do all the tagging, but we don't own any of the code bases. We're not the team building the tests and...
we help with analysis, but also, teams are doing that. So that means teams are coming to us all the time with their tagging needs, and it's up to our team to figure out the best way to give them those tagging requirements. All right. And so this is the agenda we'll walk through, and I'll just give a shout-out to my team. I'm the one up here representing Digital Data Strategy, but those folks are really the ones day in and day out doing the work and they do an awesome job. Shout-out to my colleague Amanda and Ben here back home, who do these requirements day in and day out. This is representing all their great work.
So let's talk about the intake form we use.
Why did we start using an intake form? Well, like many of you, people were reaching out to us all the time. They were pinging my team members individually.
And what happens if someone goes on vacation, right, that falls through the cracks. They weren't giving us all the information we would need to come up with comprehensive tagging requirements.
It wasn't always ready. It wasn't ready for QA. They didn't have screenshots. We couldn't help them proceed, and things were falling through the cracks. So we came up with this intake form, that helps solve that problem because they are now required to put in all of that information that really helps them think through exactly what they're asking for and make sure that the information we're getting is in a state that's ready to be, create the tagging requirements, and helps them think through the priority of it as well. So the process that we use, teams will fill out an intake form. We use ServiceNow, with new tagging enhancements or bugs that they may find. That automatically puts a cart on our board. This may look different for you all. We use Azure DevOps, you may use Jira or some other ticketing system. It also automatically emails our entire analyst team, so we all know and are aware of it and someone will pick it up for requirements. And then we acknowledge receipt of that to the submitter by starting a thread in our Teams channel, and we make sure to link the Teams thread with the card on our board so we have that historical tracking.
So some of the fields we use, of course, what is the request type? What's your site or tool or URL? Is this an enhancement or a bug fix that's going to change the priority of it in the way we approach that request? Also, who's the team? Who's the point of contact we can reach out to with questions? What's the priority and deadline of that request? Of course, that's going to change how soon we get to it.
Any background details are important. We like to ask for the impact or the value that helps us prioritize it. It also gets our developers really bought into the importance of why we're doing that tagging. We also like to know, is it a permanent change or a test that's going to change our approach for tagging? And then any steps to get into that experience. Is there a QA link? Is there certain account credentials that we need? Etcetera. Screenshots are always great or even better, a link to just go in ourselves. And then lastly, sometimes one team will submit several requests in a row. We just like to call that out with them and say, "Hey, you've submitted five requests. Which one? You prioritize these for us." So they're making that decision, not us.
All right. Just a screenshot here that just contains all the information I just talked about on the previous slide, but that's what it looks like in real life.
All right. So next, let's talk about-- Okay, we've gotten this intake form, we've gotten this request, how do we approach the tagging? We take a pretty methodical approach. Like I said, this is what Amanda and Ben on my team do day in and day out. The first thing we start with is referencing any former or current requirements documents. I'll show that document in a couple slides, but that's where we start with. We already have tagged, what do we know about this already? Let's go and add that to that same document.
We then will also often go through the site with our DevTools open, click around, see what's firing, grab screenshots, add it to our spreadsheet, again, which I'll talk about in a minute.
We start with page load tagging. So what should fire on page load, as that page load, and then we move on to click tracking.
For us, we pay special attention to any of our KPIs on our site. So for us, that's a lead, where people get into search or other unique aspects and we pay special attention to any links that might lead to one of those places and add unique tagging to it.
Let's take a look at some of the documentation we use.
So first is our Variable Map. If you've been Adobe customer for a long time, this might look familiar to you.
I didn't come up with this, so this is all Adobe.
This is our global source of truth. This lives on an external team site where everyone in the company has access to it. This is where everyone on my team goes to update it. This is where all of our internal customers go to see, every single custom eVar, prop or event or every single site that we own. So each tab on this spreadsheet represents a unique site.
You may notice some color coding on here. So some of the fields we capture, of course the event, eVar, prop, number and name, where is it hit or any notes about it, what date was it added to Adobe that helps us know how far back in time we can go to pull that data, and then some of the color coding here. So pink for us means, it's not being used anymore, we can repurpose this. Yellow is some-- Okay, we need to go in and add that date field. You may notice on the left, we've got that green. Most of those are in green. That's because that means we've added an alert for it in Adobe Analytics. We try to have a custom alert in Adobe for every single event and eVar and prop.
We also capture the implementation information. So is there context data that's particularly important for our apps.
What's the launch or tags? I'm never going to get used to calling it tags, by the way.
What is the data layer value? Or if it lives in a processing rule, what is that processing rule name? Also, we send all our data, like many of you probably, through data warehouse to our internal data warehouse, our enterprise data warehouse. So we do that mapping here as well. Again, this is our global source of truth. So what are the table names? How do those columns match? What are the column names? What is the date added to those tables? Because that might not always be the same as the date it was added to Adobe.
And then lastly, the configuration information, so these are all the Adobe admin settings. Right? The type, the serialization, is it always or once per visit, etcetera.
All right. So now that requirements template that I mentioned before, this is our version of this that we came up with after some trial and error. For us this works best with for both our analysts and our developers to be able to interpret those requirements.
So you can see here we've got screenshots, that's always really helpful. We have separate tabs for page load versus clicks. We have separate tabs if there's multiple pages on any given microsite, we'll probably have separate tabs for each of those as well.
We also have a separate tab for QA often, just so we don't muddle this source of truth view. The QA tabs are really helpful when my team is right now migrating everything from app measurement over to the web SDK, and so that usually requires a pretty extensive in testing process, and our QA, shout-out to her, she's awesome too, Khadija. She'll go in and create a whole separate tab and really mark everything, look with a fine-tooth comb.
So the included items. Right? Screenshots, page load versus click, what's the Adobe variable in value, any special notes about it, what's the data layer value that helps our developers. We also include third-party tags here, so we can see where those fire as well. Again like our variable map this is also the source of truth that lives externally on Teams and anyone can go access this and see what's firing, what should be firing, on any given site.
All right. So now I'm going to move into a section where I'll talk about some of the tagging best practices we use in general on our site. Right? So starting with pagenaming, we take a pretty customer-centric approach to pagenaming. What I mean by that is each organization, each site is going to have their own way that they like to organize it or have different teams divvy up the pages or the sites.
And it may be tempting and if that's the way your company does it, nothing wrong with that. It may be tempting to say, "This is the team that owns this page, so we're going to name it that way. This is the team that owns this page, so we're going to name it that way." For us, because the reason we do the tagging in the first place is to capture the customer's interactions, that's the point of view we like to take with tagging. Like, if a customer's on the finance section, they get the finance page level details. It doesn't maybe matter that one team might own one page, one team might own the other. It just helps get everyone speaking the same language internally.
So we take a three tier approach from the customer's point of view. So we use the out of the box channel or site section at the highest level. So in this example, a customer is on the research section of our site. We also capture that in a custom eVar, because that lets us do some more slicing and dicing and have more stickiness with that channel level.
Next, we use a custom prop for the subsection. Not every page might not have a subsection. This particular section of our site does where we've got lots of different content articles related to research about cars. So this is the trucks section of our research channel. And then lastly, we use the out of the box page, for the lowest level or most granular. And we, again, also use a custom eVar for that, so we can do that slicing and dicing and get that stickiness. You can see here that the best trucks in the research section is what our page name is going to be there, the most granular level.
Okay. Moving on to click tracking. So we use this same method globally and not just on carmax.com, but every single digital property that we own.
We like to tag where all possible, every single CTA on our site. This is going to vary for everyone else depending on your server call budget and what's important to you. But I often find that, the more you tag, the more context you're going to have to compare that data to something else. Right? It's not super helpful here to know how many people clicked on the Viewed button if you don't also have tagging on the Search button. You're not going to have a frame of reference to know if that's good or bad.
So we use a series of props on every single CTA on our site. We capture the page dynamically in a prop. We capture the link text dynamically in a prop. We capture the link position in a separate prop. I'll talk more about that one on the next slide. Then we use a prop to concatenate all those things to get the most granular level. And what that allows us to do is slice and dice that in a lot of different ways. So we can look at all the links on one page together or all the links named this thing across, doesn't matter what page you're on. Or for prop 5, if we do the header-- We can look at the header, clicks again across the site. We also add timestamp and URL to every single click.
I mentioned how we use prop 5. So by default, prop 5 will take the name of the page, but there are a lot of reasons we use a custom prop 5 for the link position. One is when you have the link with the same name on the same page. So in this example, we've got several different get prequalified links. We want to be able to understand which exact link got clicked. So we'll use a prop 5 of position. We have one for header, one for personalization, and one for the footer to understand that uniqueness.
The second reason we might use a custom prop 5 is when there's a lot of links in the same section.
If our analyst is trying to look at big sections of the page and what gets clicked on the most, we don't want them to have to go in and add up 50 links in this research by brand section to understand that customers are clicking in that section. So we use a custom prop 5 to say, "Okay, you're in the header, you're in the footer, you're in this link farm all over our site." A third reason we might use a custom prop 5 is to capture a customer's selection on submit. So for example, in this first one, we've got our finance form. We're asking, "Do you want to add a co-buyer?" This is a Radio button that's selected, but the final value isn't really selected until someone clicks that Submit button. We don't want to waste server calls clicking every single time someone's clicking yes or no when that's not going to tell us anything. That's also not going to be their checkout stage. Right? We only want to know, do they need a co-buyer when they hit Submit? Yes or no? Similarly, our sign in page here, we've got the option that says keep me signed in. We don't need to know if a customer is clicking and unclicking that button. We just need to know their choice when they're clicking that sign in button when they check out. So we'll use prop 5 to capture that status from that form. If you have multiple things like that in a form, you can concatenate those and classify them on the back end if you want.
Okay. Some general click tracking best practices. So know your KPIs, probably goes without saying, but we like to tag any link that leads to a KPI with a finding method. I mentioned leads are important for us. Anywhere on the site that we have a link that goes to a lead, we say this is the lead initiation method, so we can measure conversion rates from all those different CTAs.
We use one event for initiation of any KPI and one for submission, if you maybe have a lead form like us, so we can measure conversion rates and completion rates for those forms.
If you have a form that has multiple pages in it, you can use other events or a custom prop to measure if there are multiple pages in that form.
Accordion dropdowns, some of you might have things like this, like FAQs on your site. We only fire them on open, not close. That's going to save you server calls. But if you're firing it on open and close, you're double counting and what are you going to do with knowing that customers close an FAQ? Your situation might be different, but that's one of our best practices.
For any item like this where you have calculator fields, similar to the prop 5 thing, we don't capture a click on each time a customer is interacting with each of those different fields, but instead on submit. Your use case might be different, but again, that's not their checked out state if they're clicking multiple times on their credit score or down payment. They might be playing with this calculator on purpose to try to find the best rates, and we only really want to know what they checked out with when they click that shop with budget or get prequalified link.
We use global variables for IDs. Again, consistency, having both anonymous user ID and an authenticated user ID and keeping those the same across any site even if the ID is different, whether it's a dealer ID or a customer ID, but we have an anonymous and an authenticated in the same eVars across all our sites.
And then, our team has started doing lately, which I've been a big fan of, is we are reserving some variables and events for testing. So we've started giving each team one eVar and one event. We say, "Hey, anytime you're building the test, you can go plug whatever you want into those things. This is your eVar, this is your event." That way we're not building permanent tagging each time they're running these tests, sometimes every couple weeks for each team. That saves our analysts and developers' time, and it saves them time and we're not a blocker for them getting their test out.
All right. Let's talk about events. So different serialization helps us answer different questions. So events 1 through 500, we fire every single time that event happens, and the same corresponding number in 501-1000 fires only once per visit. That helps us answer different business questions. Like, how many times did X happen? Well, we used the first 500 level one. But for us, we have a car page, that's our most popular page on the site.
People who look at car pages tend to look at a lot of them, but we know that not everyone looks at a car page. So if we try to answer the question what percent of visits looked at a car page, we can't divide event 3 by visits, we'll get over 100%. So we have this 503, which tells us that they looked at least one in that visit.
All right. Lastly, I'll talk about how to keep your requirements consistent across sites and globally. So you want to use same variables and events across properties. Again, we have a bucket kind of set aside at the end for-- Each site is going to be a little different. Right? They're not going to have all the same things, so we have this bucket set aside for all the custom things.
We use the same variable map and structure for each one.
For us, one helpful thing is we use a combined report suite for iOS and Android apps and use virtual to separate them.
Some of the benefits. This is easier for our analyst users who may be analyzing multiple sites, different customer interactions in our omnichannel world, helps them know that eVar6 is our anonymous visitor ID across any site that they're looking at.
And it's easier for my team to manage and remember, we know that eVar6 is the anonymous user ID, anytime we see that.
In theory, you're already using best practices on one site. You might as well apply them to all the sites that you own.
This helps our native app team compare their data to .com They're constantly parallel, how's the app trending toward .com? Having all the consistent variables helps them very quickly make those determinations.
It's easier to set up tables in Data Warehouse. I mentioned we send that data down to Snowflake. If you're using the same variables and events and column names, that's going to be a lot easier again for your entire analyst community to go in and analyze.
And then, it's easier to stitch your omnichannel journey together. Look at your whole sales funnel, measure in both Adobe Analytics UI and the downstream.
All right. So key takeaways for this, you cannot over-document. I know documentation is tedious and it's boring, and not everyone's favorite job, but if you do this as you go, it's going to make your lives easier, your team's lives, your analysts' lives a lot easier, and you'll always have that source of truth document. Know your KPIs.
You might probably want to give special tagging consideration to any KPIs on your site.
Again, we approach from the customer point of view that just helps everyone in the company speak that same language.
And lastly, consistency is key. That's going to help your analysts and your users be able to really quickly analyze your omnichannel journey across sites.
All right. Thank you. That's what I had to share with you today.
[Music]
