Is it necessary to assign a new prop variable to capture 'My account sign in' event?

possible_analyt

24-10-2018

I am working on the 'My account sign in' feature for a client's website. In DTM set up, it will be an event base rule tracking 'form submit'. I plan to use an eVar (e.g. eVar80) to record the region sub-domain where the 'My account sign in' (since the website has multiple regions' sub-domain) and an event variable (event 80) as a counter for the number of times the event happen. However, i am a bit hesitant to use a prop variable (prop80) to record the region sub domain, reasons are:

- It repeats the same information of eVar80

- # of prop variables are limited to 75 so it is precious resource.

Want to have some insights and opinions on this.

Accepted Solutions (1)

Accepted Solutions (1)

gflare

30-10-2018

There's no hard rules for when to use an sprop vs an evar, and most of the information you'd find by googling is based on old reporting (i.e. not counting the new functionality in Analysis Workspace).

The old rule of thumb was pretty much:  "sprops if you need the classic pathing reports" , "evars if you want to use success events as metrics" .  Both of them are just about dead in the water now, since Analysis Workspace is so awesome.  I still hold by the "sprops for pathing" rule - due to some issues still within workspace, but everything else is capable with an evar now (remember that evars can have hit expiration so that they act like sprops).

Here's the official implementation documentation on the topic, towards the bottom it has a realistic look on which to use: Comparing Props and eVars

Which to Use

Tip: If you don't want an eVar to persist, you can change its expiration to 'hit' so it doesn't keep any data beyond the hit.

Answers (2)

Answers (2)

gflare

25-10-2018

The short answer is 'no, you don't need to use an sprop' .  As a general rule-of-thumb, you're doing things correctly by collection a custom event (sign in), and then collecting one or many eVars in order to break it down (sub-domain).