Five Reasons to Create Custom Variables in Adobe Analytics When OOTB Variables Exist

In Adobe Analytics, there are a number of out-of-the-box (OOTB) variables available for setup. Additionally, most contracts include 200 custom eVars, 75 custom props, and 1,000 custom events. Those numbers may seem low to you, or perhaps, they seem quite high! 

Regardless, you may be asking yourself what the benefits are for creating custom variables that seem duplicative of OOTB variables. Let’s chat through five use cases where you might consider creating custom variables.

1. Size Limitations

Many OOTB dimensions have a 100-byte limit. Custom eVars, however, have a limit of 255 bytes. This can come in handy if, for example, you’re dealing with long page names which Adobe will truncate in the Page dimension. 

To store more data, consider creating a custom eVar for Page Name. This custom eVar will have a 255-byte limit, more than doubling the maximum size limit of the OOTB variable.

2. Classification Options

Perhaps you have a client who wants to group Zip Codes into sales markets. We can group these using a classification, right? Not so fast… you canNOT classify OOTB variables. So, if you have Zip Code stored in the OOTB dimension but no custom dimension, you’re out of luck. You’ll have to try a potentially lengthy and messy workaround like segment creation to solve this need. Sure, you can create a custom dimension for Zip Code now, but you won’t have historical data, because you didn’t collect it.

On a positive note, classifications are retroactive with a lookback window of up to six months. With classifications, you’re not altering the actual data collection. You’re simply changing the way that data shows up within Analytics. 

If you implemented a certain eVar on January 1st and then decide you want to classify it on March 15, your classification will be applied to all data that has been collected in that eVar — from January 1 to March 15 and into the future! 

You can’t classify data prior to January 1, because you didn’t collect that data in the eVar. You can, however, modify your classification at any point and your changes will be applied retroactively (for up to six months). Keep in mind that this introduces greater flexibility, but also some risk if not done properly. OOTB variables, on the other hand, can not be classified when the values don’t show up as expected. That brings me to my next point.

3. Data Backup

Some OOTB variables are especially important to your business. If an OOTB variable breaks, wouldn’t it be nice to have a backup so the data isn’t completely lost? This has happened before, and it could happen again. It’s a best practice to create custom variables for your most important metrics and dimensions, that way they’re always backed up.

4. Data Consistency

A few OOTB variables have default values you may not want. For example, if s.pageName is not set or blank, the OOTB Page dimension will populate the full URL by default. If your site works with a lot of  URL parameters, reporting on Page can get pretty messy, since the version with and without query parameters will be treated as separate line items in reporting. 

On the other hand, if a custom eVar is not set, you will simply see “Undefined” in your reports. This undefined bucket will sum up all of the occurrences, so you can understand if this is a big issue on your site. 

Additionally, you can then break down this Undefined bucket by Page URL or another variable as desired. Keep in mind that Undefined can either be a result of the variable not being set in the code or of you trying to combine a dimension and a metric that simply can’t be combined. 

If you are interested in learning more about those “falsy” values, check out the article "Unspecified", "Other", and "Unknown" in reporting. 

5. Customization Options

Perhaps you want your variable to have a specific expiration or allocation. Perhaps you want your variable to gather a list of items and break them out as single line-items in reporting. For the most customization options, create custom variables and get exactly what you want. 

Sure, ordering off the menu is easy. But maybe you know exactly what you want, and it’s a variation of something on the menu. Customize your order — make the data your own. Get what you want with custom variables, and (of course) don’t forget to tip your waiter analytics engineer. 😉

While you’re considering this option, definitely check out Adobe Attribution IQ to see if it covers your needs. The Attribution panel in Workspace allows you to select an eVar, Success Event, and one or multiple attribution models. It then automatically creates multiple visualizations to view your data. Depending on the customization you’re looking for, this option may be all you need!

In Conclusion

Creating custom variables may take some setup time upfront, but they can really save you later if you run into one of the scenarios listed above. Because custom variables are limited in number for most contracts, it’s not advisable to have a duplicative variable for every single OOTB variable, or even worse, have an eVar AND a Prop for every single OOTB variable. You’ve probably heard the case for no longer using props, and it’s a good one! We highly recommend giving Jan Exner’s blog “Out with the Old!” a read if you haven’t already.

There are still some OOTB variables we regularly store in custom variables to prevent one or multiple issues listed above. Some of our favorites:  

Events:

• Page Views
• Searches (if applicable)
• Orders (if applicable)
• Units (if applicable)
• Revenue (if applicable)

eVars:

• Page Name
• Page URL
• Experience Cloud ID
• Zip Code or other geo dimensions (if desiring classification)

Happy Customization!