prop/evar/events-need suggestion

[sweety10]

Hello everyone,

I listed few data elements assigned with respect to eVars, Props, Events

Can anyone guide me whether i assigned correctly or did i go wrong anywhere in identifying.

Thankyou in advance.

props:

pageName:props
channel:props
pageID:props
sitesection : props
language:props
country: props
userID:props
loginStatus:prop
productID:prop
productName:prop
noofproduct: props
cartTotals: props
productSubtotal: props
shippingDetails: props
totalCheckout:props
productStatus:props
applicationID: prop
pplicationname: prop
applicationStatus: prop
applicationTag2:prop
name:prop
email:prop
website:prop
productID:prop
productQty:prop
productName1:prop
productName3:prop
transactionName:prop
transaction:prop
error:prop
errorName:prop
errorType:prop
random
cookiename
constant
pageifo
sitesection

evars:
productcategory: evar
productsize: evar
productcolor : evar
productPrice: evar
productID-evar
zipcode: conversion variable pre define
StateName: conversion variable pre define

events:
Tax:
Shipping:
stepevent for serialization

[Pablo_Childe · Accepted solution]

Hi your concern even confusion is totally justifiable. I thought I could make a recommendation to perhaps help you as in some cases some things are better of as props some as evars and some as events.

Props: think of them as just a data variable populated. All you have listed could in deed be ok as a prop. The challenge with props is they are more or less a finite variable(pagename the props lists all pages for example). Props are not sticky in other words they don`t typically follow a user more hit based. 

Evars: to me these are the real powerhouse items in adobe analytics. Evars are in essence a variable occurrence that will follow a user as they navigate across pages. (they are sticky and you can control how you track them, duration or if they change state). Most familiar use is when used to track a tracking ID. Basically think if you want to capture a users state, state of an action during a visit then evar is often times the way to go.

Events: This are basically a customized series of actions, events that when defined and grouped together end up being quantified as a event. Events are instance /occurrence based, Example use for a custom event could be: fill out a registration form.(Complete a form event), make a special purchase for a particular tool. (special tool purchase event). change some info in a personal form. (Form edit event). Basically think of things that are specialized event not already covered by standard Adobe events. In some cases you maybe fire multiple events at once. So a generic s.purchase event , plus special tool purchase event. It really depends on the reporting requirements and how you want to group and report on things.

Looking at your list one thing I would add is:

userID:evar
loginStatus:evar

I would transfer these to also be evars. That way you can follow users across pages with these tidbits, If page even doesnt have the info the evar of previous page will follow the users.

GLTU

[Jennifer_Dungan]

Excellent advice @Pablo_Childe 

One more thing to consider is the amount of data that can be held...

props truncate at 100 characters, while eVars truncate at 255 characters... so if you need to capture more than 100 characters, an eVar would be better (you can still set the expiry to "hit" so that it works the same way as a prop). Such as if you need the URL of the page to e capture (where you can access it in workspace, and not just in data exports), using an eVar is probably a better choice.

Special parameters like product don't truncate at a certain length, so you can pass many items, but the values inside the products notation do have limitations.

[Alexis_Cazes_]

Product data

Adobe provides you a variable to send products data and I would advise you to use it instead of using eVars/props.

These are the delimited sections you can provide:

• Product name (required): The name of the product. The maximum length for this field is 100 bytes.
• Quantity (optional): How many of this product is in the cart. This field only applies to hits with the purchase event.
• Price (optional): The total price of the product as a decimal. If quantity is more than one, set price to the total and not the individual product price. Align the currency of this value to match the currencyCode variable. Do not include the currency symbol in this field. This field only applies to hits with the purchase event.
• Events (optional): Events tied to the product. Delimit multiple events with a pipe (|). See events for more information.
• eVars (optional): Merchandising eVars tied to the product. Delimit multiple merchandising eVars with a pipe (|). See merchandising eVars for more information.

Also I would advise you to not send some of the product name but the product SKU/ID. We can see that you are sending product size, color etc... These are metadata and I would not bother sending them or even setting code to gather this data. It is better achieved using classification. Once you send the SKU you can then create classification as you see fit and upload the metadata file into Adobe Analytics. New classification reports will be created and metrics will be automatically assigned and deduplicated etc as needed. Also it is retroactive meaning that you can always upload more data or remove some data and it will be applied to historical data.

Next use the event purchase event. As you will pass the quantity and price as part of products variable, by using the purchase event this will allow the Revenue, Order and Units to be automatically incremented. Also I would advise you to use purchaseID variable. This will allow you to make sure that the order is only counted once (i.e if customer reload the thank you page we do not want to send order twice). 

Next for shipping/tax, you can use normal events to send this data, please be aware that if you send the events outside the products variable it would be assigned to all products at the same time. Also configure the event in correct format, currency one and not numeric one. If you want a bit more details you can use additional details to be send as part of the products variable for each product.

/**
 * tax for sku1 is 1.11 and shipping is 2.02
 * tax for sku2 is 5 and shipping is 5
 * Overall tax stored in event3
 * overall shipping stored in event4
 */
s.events="event3=6.11,event4=7.02";
s.products = ';sku1;1;10;event1=1.11|event2=2.02,;sku2;5;100;event1=5|event2=5';

Also for cart events predefined one exist and should be used:

https://experienceleague.adobe.com/docs/analytics/components/metrics/checkouts.html?lang=en

https://experienceleague.adobe.com/docs/analytics/components/metrics/carts.html?lang=en

https://experienceleague.adobe.com/docs/analytics/components/metrics/cart-additions.html?lang=en

https://experienceleague.adobe.com/docs/analytics/components/metrics/cart-removals.html?lang=en

https://experienceleague.adobe.com/docs/analytics/components/metrics/cart-views.html?lang=en

https://experienceleague.adobe.com/docs/analytics/implementation/vars/page-vars/events/events-overvi...

• purchase: Increments the ‘Orders’ metric by 1, and takes values set in the products variable to calculate ‘Units’ and ‘Revenue’. See purchase event for more information.
• prodView: Increments the ‘Product Views’ metric.
• scOpen: Increments the ‘Carts’ metric.
• scAdd: Increments the ‘Cart Additions’ metric.
• scRemove: Increments the ‘Cart Removals’ metric.
• scView: Increments the ‘Cart Views’ metric.
• scCheckout: Increments the ‘Checkouts’ metric.

Props vs Evars

Now which one to use and when. Props should be used primarily to traffic data so data that expired on hit and do not persist. Also they are limited to 100 characters so this needs to be taken into account. Historically props where the only one to have pathing enabled but it seems eVars have this functionality now. Also by default props have a linear allocation for all metrics. 

eVars should be used for values that persist or for data that you want to give full credit. They can be configured for different allocation but I believe last/most recent is the configured by default so I will give full credit for a metric.

Also eVars are limited to 250 characters

Application data

Evars and props are not unlimited depending on your contract you will have more or less but eVars only goes to 250. This seems quite a high number but believe me that they run out fairly quickly.

If it is possible it is advised to group same data under the same variable as long as they have same allocation and expiration.

This is usually the case with application data. I use an eVar report in my implementation called application attributes where I put values dlimited by a | and then use classification to split the values in their own reports

s.eVar1 = "name=App full1|status=START|tags=tag1,tag2"

Once you have set up classification, use classification rule builder to automatically classify your data

Hope this helps