- TLC Home Home
- Discussions Discussions
- Documentation Documentation
- Knowledge Base Knowledge Base
- Education Education
- Blog Blog
- Support Desk Support Desk
04-11-2018 12:44 AM - edited 04-11-2018 12:47 AM
Hi all
We are looking at ways to better organise data layer, extensions and tags in modular libraries. In an environment with many different profiles, the whole stack of the datalayer and extensions is rarely used by one profile. Instead, there are some profiles that make use of e-commerce variables (and related extensions), some only need a basic setup and others are content platforms that would require yet another set of datalayer variables and extensions.
We could easily split up the data layer and extensions in logical "packages". The problem is mapping variables to tags with a large number of mappings, typically Analytics tags. Ideally, those tags would be managed in one place. But given the diversity of the platforms, the mapping would be very different for the a.m. profile types. Not feasible with the ootb tag mapping.
The idea is to do the mapping in a Javascript extension scoped to the respective tag. Ie. overriding the *u.map* part of the tag template with that extension.
Is that something you would recommend or is there another way to achieve a flexible mapping?
Many thanks for your thoughts
Solved! Go to Solution.
04-11-2018 01:15 AM - last edited on 04-11-2018 06:30 AM by kathleen_jo
Personally, @jmbolfing, that's how I would do it.
Right now, we're doing exactly the same to align a dozen different DoubleClick tags to use an identical mapping, by using a tag-scoped extension mapped to all DC tags which runs:
u.map = { "DC_type": "type", "DC_cat": "cat", "DC_src": "src", "GDC_FPC": "u8", "Brand": "u1", "ProductGroup": "u2", "ProductSubGroup": "u3", "JourneyStep": "u4", "JourneyAction": "u5" }
This allows us to force conformity across the different tags without having to manage individual mappings through the interface, and risk missing a tag when making changes.
We've also created extensions that create dynamic mappings based on the contents of the UDO, so for example iterating over the b object and for any variable called, say, Doubleclick_x create a mapping to "x", so I could populate variable u54 simply by attributing a value to b.Doubleclick_u54 without having to explicitly map every single possible variable.
So yeah, looks like a good plan to me, obviously JS extensions are more complex to maintain than UI mappings, but the flexibility is worth it..
Copyright All Rights Reserved © 2008-2023