Allow for customized variable identifiers

[#1]

It would be great if Adobe Analytics allowed customers to identify variables in the Admin console as they wish instead of having to use "event1" or "event2"

If users could pick their own names, they could more easily make implementations align across multiple report suites instead of having to worry about pre-defined variable slots for events, eVars and sProps.

For example, if you defined internal searches as event.internalsearch, you could make that consistent in all implementations vs. having to make sure all report suites used the correct event number.

This would also make it easier to share objects across implementations.

[#2]

Please look into using Context data variables + processing rules.

Context Data Variables

[#3]

Unfortunately, context variables don't help when it comes to the Admin Console and keeping your implementation organized across multiple report suites...

[#4]

Before going further, I agree, it'd be nice to get out of the event1/evar2/prop3 game. So I'm on board with you.

But I'm curious - why don't context data variables keep an implementation organized across multiple report suites?

[#5]

The issue is that the Admin console is where people go to select all of their report suites and maintain the variable names and settings.  I guess you could use an Excel spreadsheet to document all of your context variables and hope everyone does it correctly across all report suites, but the beauty of the admin console is that it shows a MULTIPLE warning if any suites are inconsistent.  I love that, but it only works if you stick to the event1, event2 model.  As you know, that model stinks if you have different types of websites.  Forcing everyone to use the same variable numbers rarely works.

I'd like to have a way to do exactly what the admin console does, but allow you to pick the hidden variable name/ID. So instead of using event1 for Internal Searches, you might call it something like "aa-internalsearches."  Then any site that has internal searches can use that name/ID (and roll-up the data into a Global if needed) and not worry about the slot number.  I think context variables are a great start, but there isn't (to my knowledge) a way to document them and coordinate them in the admin console.

In addition, imagine if a standard were to emerge across all Adobe Analytics customers in which everyone agreed to call their internal searches success event the name above? In that case, you could make calculated metrics that could be shared across different company logins!  We could all come up with some standard names and share workspace templates, alerts, segments, etc... because the definition of these elements would be the same across all orgs.  Taking it some step further, you could build ReportBuilder dashboards, Tableau dashboards and do API calls that could be shared with the entire Adobe Analytics community...

The idea sounds small, but the potential is actually HUGE!

[#6]

I love this idea! might be a lot of work to change the current setup (both on Adobe and client side) but might be worth in the long run...

[#7]

Generally, this idea would also help to build a cross-company guide for best-practice implementations that would allow especially new companies to more successfully onboard Adobe Analytics. In more detail: if we were to document a set of best practices how to implement a certain cross company requirement, such as "Ability to count how often users search for, and what search criteria was entered" including documentation on which dimensions and events to reserve and how to configure these.

I believe that a namespace concept for variables (Namespace - Wikipedia ) could further help to design global requirements, where we can assign, for example to an evar:

• the traditional number: "evar1"
• the label "Search Criteria"
• a namespace: "global.aa.internalsearch.searchcriteria" (which is an alternative unique identifier)

If we would then be able to build Analysis Workspace dashboards based on namespaces, we could share these between companies. The same would be true for many other object (segments, calculated metrics).