hashow.blogg.se - Omniture integration guide

In this scenario, we’d use a Success Event to count article downloads, and an Evar to capture and persist the type of entry pages. perhaps place links for other articles on high performing entry page types, or work to surface underperforming page types higher in search result listings). With this information we could optimise our operations (e.g. As a business, we want to know which entry page types are driving the most downloads. We can then (for instance) focus on investing in favourable ‘states’ and ‘repairing’ underperforming ones.Īs a concrete example, assume we are a publishing company and we want to count the number of times an article is downloaded. In other words, we can measure how certain usage ‘states’ drive success i.e., the set of Evar values that are most effectively contributing to our successes. When a given success event takes place subsequently during app/site usage Adobe assigns credit to each value in all currently set Evars. We set data-descriptive values in Evars, and these values persist beyond the tracking call in which they are set. While Events count ‘interesting things’, we use Evars to ascribe facts about what we’re counting. Examples of Evars might be ‘hashed user ID’, ‘page type’, or ‘app name’. Examples of events might be ‘Article Downloads’, ‘Stream Starts’, ‘Game Plays’, ‘Gametime spent’. Success Events are often referred to as ‘events’, ‘metrics’, ‘successes’, and ‘counters’. Likewise, we can define up to 250 (depending on contract) custom Evars if the builtin Evar set isn’t enough to meet our needs. We have available numerous builtin events, and we can also define our own (up to 1000). Success Events count granular positive occurrences on our sites and apps. Evars are frequently interchangeably referred to as ‘conversion variables’, ‘eCommerce Variables’, ‘dimensions’, and sometimes just ‘variables’.Įvars are inextricably linked to ‘Success Events’ in Adobe. Props let us analyse t raffic, but Evars let us analyse the granular success events pertinent to our specific business requirements. While props provide useful insight into general traffic characteristics, they don’t reveal much about what actually drives specific desirable outcomes (or what decreases the likelihood of undesirable outcomes). Props tend to be processed pretty quickly by the Adobe Data Collection Servers.

Only certain metrics can be crossed with props in Analytics reports.

Props are not persistent, they only have meaning within the context of the tracking call in which they appear.

In this way, we can count the number of times each of our promos were seen by Visit, Unique Visitor, and so on. This prop – call it ‘Prop2: Internal Promo Instance’ – would only be set on pages with an internal promotion, and would be set to the name of the promo shown to the user. For instance, if a business wishes to count the number of times a user saw a particular internal promo ad on their page they could utilise a prop. While the above example is more about segmenting traffic in general, we can also use props to ‘count’ more unique situations. When a user navigates through this sample site, each time they invoke a pageview with ‘Prop1: Site Section’, Adobe will count the number of different values a user has ‘seen’ for this prop during their tenure. Examples of Site Sections might be ‘Home’, ‘Menswear’, ‘Formalwear’ for a clothing retailer. Therefore, ‘Prop1: Site Section’ will need to be set on all pages (as every page belongs to a section). We could reserve a prop – call it ‘Prop1: Site Section’ – storing within it the name of the section a given page belongs to. Say we want to measure the number of Unique Visitors, and how they interact with our site based on Site Section. Adobe Analytics traditionally provides 75 slots for us to define our own props, so you can get pretty flexible! Pageviews, Unique Visitors and Visits) that are frequently broken down and analysed using props.

There are numerous such ‘traffic’ metrics in Adobe (e.g. Props are tools for counting and segmenting topline information about our user traffic. Props are referred to interchangeably as ‘props’, ‘sprops’, ‘s.props’ or ‘traffic variables’ (we’ll refer to them as ‘Props’ throughout the rest of this article).