What is the difference between custom link tracking and having events for a specific link click event? For example there is a link in page I can use custom link to track it and I can also use events from success events. Whats the difference and when to use custom link and events?
Also this question is not restricted to only events. If you know any cheat sheet kind of things which tells when to implement evar, prop, event, custom link that would be great.
Solved! Go to Solution.
Views
Replies
Total Likes
I believe there is a lot of stigma around using "instances" and I'm not sure why... yes, way way back in the old days of "Reports" instances wasn't good... but with the way that Workspace works and the ability to build out segments on the fly to give context to your instances, I don't get any difference in value....
So in my implementation, I look at how I am planning on using something, and ask the following questions:
If this is a "not so important" type of event, sometimes I will save using an actual specific event, cause we have a limited number of those.
Sometimes if the event is semi-important, I will use a generic custom event like "general clicks" or "expand" / "collapse" that is used on multiple items across the site that have the same type of action, despite being a different element (then rely on the custom link name or some custom props/eVars to provide context).
Other times, for really important metrics, that I know lots of people will want to use, I will create specific events to pair with the actions.
Then I look at the next question, how and where is it going to be used... my "successful login" for instance can be triggered from our login page, but it's also triggered during the subscription payment flow for new users (but not for existing users who are already logged in), and it's also triggered on on a few other actions... since these actions all have different naming conventions and the current state of the user is part of the "will it/won't it trigger" logic, it's easier for me to have 1 custom event that can be triggered when relevant, regardless of the "custom link naming convention".
Then of course, it comes to Mobile Apps (which I track along with my websites in a global suite)... I really hate that Adobe forces the "AMACTION: " prefix onto my custom links... because I already have a prop that tells me where the action was triggered from, and I want to see the exact same name for my custom link no matter where it was triggered from; but I have no choice.... IF I don't want to create a segment to pull the web name and the mobile app name variants together, sometimes again it's easier to just use a custom event for them.
But again, we have limited custom events available to us, so I basically evaluate the needs on a per use basis... importance, who will be using it, and is it triggered in multiple contexts or only one... I think about how I will report on the data and make a decision based the above about how I will proceed with my tracking implementation.
So in short, you can track a custom link with or without having a specific custom event... if you don't use a custom event, you can use the standard "Custom Link Instance" metric and segment it based on the Custom Link value.
Whats the difference and when to use custom link and events?
Custom Links are basically your s.tl() (web) and trackAction (mobile app) calls... these do not increment your page views... they are actions... they can be clicks on buttons, success events like "login success", "form submitted success", etc. They can be paired with events, or not... depending on your needs.
Events can be set on Page Views or Actions. You can set your own custom events such as "Content Page Views" and only trigger that event on your content pages (i.e. articles, blog posts, videos, podcast, etc) but not on your home or section pages, etc... basically it would be a targeted "Page View" for a specific page type. You can also use Events on a page to indicate the presence of some item that may not always appear... i.e. you might have a promotional banner that only shows once a week, and only to users that fall into a certain group... you could use an Event to track the "banner impression" (or loaded, or whatever terminology you choose). So then you can see your Page Views separate from the number of views your banner got (since it doesn't always load).
While you could use an action to track the banner impression, this would require a separate server call, which will cost you money, the event (added to the page view) would mean only one server call on the page... every little bit counts. However, if the banner shows up after the page view, then you have to track it as an action...
If you know any cheat sheet kind of things which tells when to implement evar, prop, event, custom link
I don't know a cheat sheet off hand, but here is some advice:
1. eVars have "persistence", so if you want to track something when a user enters the site, or performs some action, and have that value remain for the rest of the session, or for a week, or until they make a purchase, etc... eVars are the best for that
eVars also have a 255 character limit, so if you want to say store the URL or a longer version of the page name (which could also then be correlated to your actions/custom links), you can use an eVar set with a Hit expiry.
2. Props are always "hit" level... they have a character limit of 100. There are good for fairly short variables that need no persistence... another cool thing about props is that you can turn them into lists... so let's say you have articles that normally have one author, but sometimes have 2... you can set up a prop with a delimiter (I like to use pipes since they are unlikely to appear in a person's name "|") and you can pass both names into the prop.. it doesn't matter what order the names are passed:
In this case, the report will look like:
author one 3
author two 3
author three 1
3. Events are counters essentially, usually they increment by 1, but you can make them numeric, which allows you to pass a custom incrementation (i.e. s.events = "event1=5"), or you can make them currency based (i.e. s.events = "event1=9.99")
These can be used on page views or events. They can be simple page view indicators for specific pages like my sample above, they can be used to indicate the when actions are performed, they can be used to count conversions (like newsletter sign ups, or purchases), etc
4. Custom Links, while the name indicates "link" this is kind of a older naming convention... I tend to think of "Custom Links" more like "Custom Actions". I do use them on special links and buttons, I also use them sometimes when backend functionality is triggered to count completions of certain events... for instance... I don't track "clicks" on my form submit buttons... cause if the form fails to send, I am over counting... instead, I trigger when the form successfully submits (I work with my developers to help me detect the completion so that I can have better data).
We also have some overlays that appear upon "exit intent"... I don't want those to count as page views, I just want to know that the overlay was triggered, so I use the "custom link" to track when the overlay is shown (even though the user isn't actually clicking anything).
I hope this gives a you some ideas on the differences and where to start... the best thing you can do is to use a Dev suite and play with it... try different things, try to see what happens with different settings...
And if you have specific questions, we are here to help.
I believe there is a lot of stigma around using "instances" and I'm not sure why... yes, way way back in the old days of "Reports" instances wasn't good... but with the way that Workspace works and the ability to build out segments on the fly to give context to your instances, I don't get any difference in value....
So in my implementation, I look at how I am planning on using something, and ask the following questions:
If this is a "not so important" type of event, sometimes I will save using an actual specific event, cause we have a limited number of those.
Sometimes if the event is semi-important, I will use a generic custom event like "general clicks" or "expand" / "collapse" that is used on multiple items across the site that have the same type of action, despite being a different element (then rely on the custom link name or some custom props/eVars to provide context).
Other times, for really important metrics, that I know lots of people will want to use, I will create specific events to pair with the actions.
Then I look at the next question, how and where is it going to be used... my "successful login" for instance can be triggered from our login page, but it's also triggered during the subscription payment flow for new users (but not for existing users who are already logged in), and it's also triggered on on a few other actions... since these actions all have different naming conventions and the current state of the user is part of the "will it/won't it trigger" logic, it's easier for me to have 1 custom event that can be triggered when relevant, regardless of the "custom link naming convention".
Then of course, it comes to Mobile Apps (which I track along with my websites in a global suite)... I really hate that Adobe forces the "AMACTION: " prefix onto my custom links... because I already have a prop that tells me where the action was triggered from, and I want to see the exact same name for my custom link no matter where it was triggered from; but I have no choice.... IF I don't want to create a segment to pull the web name and the mobile app name variants together, sometimes again it's easier to just use a custom event for them.
But again, we have limited custom events available to us, so I basically evaluate the needs on a per use basis... importance, who will be using it, and is it triggered in multiple contexts or only one... I think about how I will report on the data and make a decision based the above about how I will proceed with my tracking implementation.
So in short, you can track a custom link with or without having a specific custom event... if you don't use a custom event, you can use the standard "Custom Link Instance" metric and segment it based on the Custom Link value.
Whats the difference and when to use custom link and events?
Custom Links are basically your s.tl() (web) and trackAction (mobile app) calls... these do not increment your page views... they are actions... they can be clicks on buttons, success events like "login success", "form submitted success", etc. They can be paired with events, or not... depending on your needs.
Events can be set on Page Views or Actions. You can set your own custom events such as "Content Page Views" and only trigger that event on your content pages (i.e. articles, blog posts, videos, podcast, etc) but not on your home or section pages, etc... basically it would be a targeted "Page View" for a specific page type. You can also use Events on a page to indicate the presence of some item that may not always appear... i.e. you might have a promotional banner that only shows once a week, and only to users that fall into a certain group... you could use an Event to track the "banner impression" (or loaded, or whatever terminology you choose). So then you can see your Page Views separate from the number of views your banner got (since it doesn't always load).
While you could use an action to track the banner impression, this would require a separate server call, which will cost you money, the event (added to the page view) would mean only one server call on the page... every little bit counts. However, if the banner shows up after the page view, then you have to track it as an action...
If you know any cheat sheet kind of things which tells when to implement evar, prop, event, custom link
I don't know a cheat sheet off hand, but here is some advice:
1. eVars have "persistence", so if you want to track something when a user enters the site, or performs some action, and have that value remain for the rest of the session, or for a week, or until they make a purchase, etc... eVars are the best for that
eVars also have a 255 character limit, so if you want to say store the URL or a longer version of the page name (which could also then be correlated to your actions/custom links), you can use an eVar set with a Hit expiry.
2. Props are always "hit" level... they have a character limit of 100. There are good for fairly short variables that need no persistence... another cool thing about props is that you can turn them into lists... so let's say you have articles that normally have one author, but sometimes have 2... you can set up a prop with a delimiter (I like to use pipes since they are unlikely to appear in a person's name "|") and you can pass both names into the prop.. it doesn't matter what order the names are passed:
In this case, the report will look like:
author one 3
author two 3
author three 1
3. Events are counters essentially, usually they increment by 1, but you can make them numeric, which allows you to pass a custom incrementation (i.e. s.events = "event1=5"), or you can make them currency based (i.e. s.events = "event1=9.99")
These can be used on page views or events. They can be simple page view indicators for specific pages like my sample above, they can be used to indicate the when actions are performed, they can be used to count conversions (like newsletter sign ups, or purchases), etc
4. Custom Links, while the name indicates "link" this is kind of a older naming convention... I tend to think of "Custom Links" more like "Custom Actions". I do use them on special links and buttons, I also use them sometimes when backend functionality is triggered to count completions of certain events... for instance... I don't track "clicks" on my form submit buttons... cause if the form fails to send, I am over counting... instead, I trigger when the form successfully submits (I work with my developers to help me detect the completion so that I can have better data).
We also have some overlays that appear upon "exit intent"... I don't want those to count as page views, I just want to know that the overlay was triggered, so I use the "custom link" to track when the overlay is shown (even though the user isn't actually clicking anything).
I hope this gives a you some ideas on the differences and where to start... the best thing you can do is to use a Dev suite and play with it... try different things, try to see what happens with different settings...
And if you have specific questions, we are here to help.
Think about it in a different approach. For all trackings, there are two types, one will increase the count of page views (s.t() for web and trackState for app) and one will NOT increase the count of page views (s.tl() for web and trackAction for app). The one that will not increase the count of page views is usually called a custom link, due to the history of a pageview and non-pageview (custom link) tracking for websites in the past.
For the "custom link" dimension, you can think about it as a "page name" for the page view tracking. The key element/identifier of the page view tracking is the page name to tell you which page it is. The "custom link" dimension tells you which "custom link" is being tracked. I personally do not use the "custom link" dimension as the non-page view tracking can be a lot of things: file download, form submission, site search, etc. It is quite impossible to have a good design of name convention for the "custom link" dimension.
You can have any number and combination of evar, prop, and event on pageview and custom link tracking as long as that fits your tracking purpose. I usually have at least one event and one evar for each of the tracking as the primary counter and primary identifier, such as "page views" and "page", "# of downloads" and "name of the file downloaded", "# of form submission" and "form name", and "# of site searches" and "search query".
On top of the primary counter/identifier, there will be additional events and evars as necessary, such as:
So when it comes to reporting, picking up the desired event and evar to build the report.
Views
Likes
Replies