Is it possible to pass query parms that are set on link click to override the one set on page URL?

[veerender_reddy]

Issue:
Step 1: I have accessed page www.test.com?oid=test1
Step 2: The page has link test2 with href ="/test2.html?oid=test2"

When I click on 'test2' link the qp parameter of page (oid=test1) is getting passed, rather than the one that is being set on link.

Requirement: I want oid = test2 to get passed, when I click on 'test2' link

[STerjeson]

Hi @veerender_reddy, what I would do is create another data variable (UDO variable type, not qp) that grabs that part of the href string. Because the link is on the same page, clicking a link that contains an oid the browser does not recognize this as having or updating the querystring.

What you need to do is treat it as a string variable and split out that part using a jQuery onHandler extension mapped to your new variable (and narrow the conditions as needed), and use something like:

$(this).attr('href').split('oid=')[1].split('&')[0];

[veerender_reddy]

Is there any way, where I can use 'qp' param and override the 'qp' param set on the page, when a link click event is triggered, @STerjeson?

[STerjeson]

@veerender_reddy Because querystrings are basically a "browser functionality" element, it is not best practice to hijack them for non-standard use. It can create unexpected problems in the user experience. It is also not possible to select a qp. variable in the interface to set a new data value in that way.

That being said, if its mission critical to hijack the functionality to do this, you could do so with some custom scripting in a javascript extension, I just would not recommend doing that when its so much easier to handle by creating and using a new data variable.

[veerender_reddy · Accepted solution]

Thanks @STerjeson. Yes, it is mission to critical to hijack the functionality on link click. I will try the JS extension approach to override the 'qp' value.

[ravi_thati]

@STerjeson, In addition to what Veerender mentioned.

We need to send 2 tags as below.

1. Page view tag with "oid=test1" from the querystring on the page --> sent to a propX

2. Link click tag with "oid=test2" from the href of the link --> Sent to the same propX.

So, does it work fine, if  I have 2 datalayer parameters(one qp & one UDO) and mapped to single propX ?

If so, would I still get page "oid=test1" on a link click tag(2nd case) when there is no "oid" in href of the link ? 

[STerjeson]

@ravi_thati , @veerender_reddy  I would create a consolidated variable that checks to see if the secondary value is populated and use that instead of the default. One way to do that is outlined below.

Variables:

oid_prop -- UDO variable to map to tag propX

oid_href  -- UDO variable for link click value

qp.oid     -- original URL qp value

2 Set Data extensions,

• one to set oid_prop with qp.oid if oid_href is not defined,
• and one to set oid_prop with oid_href if it is defined.

Then just have the consolidated oid_prop variable mapped in the tag as a single point of reference. This could probably be refined, but hopefully a starting point for you.

[ravi_thati]

 @STerjeson - as we have 16 such query params, I might have to think abit about the solutions you gave and choose the best one suitable for our app. 

Thank you very much for the suggestions, they are really helpful !

[STerjeson]

@ravi_thati One other option would be to just try setting in the js extension script (as part of the broader link call):

utag.data["qp.oid"]="12345";

My only concern with that approach is the utag.data reprocessing sequence with a link or view event. One of the Tealium engineers might be better equipped to answer that more defintitively. I don't want to see your custom qp.oid overwritten when the utag.data reloads and may grab the querystring values again. If utag only pulls the querystring once on the initial call, then it might not be a problem. Its just not something I have directly tested before.

[ravi_thati]

You are right, utag pulls the querystring values each time a tag fires. But anyway the extension runs after that, so there are no issues with it. I did a quick test with the JS extension approach and it seems to be working as per our requirement. I would probably go with that approach unless I see any other issues in my testing.

Thanks !

[craig_rouse]

I agree with everything that @STerjeson has said here. The best option would be to create a new variable and set it using a set data values extension (or multiple extensions), and have conditions to check which value you need to populate the variable with each time.

If you do decide to override the "qp.oid" variable, be sure to use the "b" object, rather than utag.data. All tags and extensions should use "b", as utag.data will only be read when the utag script initializes; "b" will always contain the most up to date values inside an extension. There are some exceptions, such as "DOM ready" extensions, or "Pre-Loader", but all other extensions have access to "b".

There is one other option that may work: you can map different values to the same mapping (e.g. "qp.oid" could be mapped to "prop1", and "click_oid" could also be mapped to "prop1" - just an example). In theory, the one that is lower in the mapping list would win, so if it was a page load, and the click variable didn't exist, the "qp.oid" variable would win, but if the event is a click, and the secondary variable is populated, this one would win. There is one caveat to this: technically, the mappings are stored in a plain JavaScript object, and when we loop through the object to assign the mappings, there is no guarantee of the order in which they will be evaluated. However, most browsers will now evaluate/loop through JavaScript objects in the order in which the properties were defined (there may be some exceptions), so in the vast majority of cases across the major browsers, you should find that mapping multiple values to the same mapping will work as expected, and the lowest one in the list in the UI would win. This means you could have as many different items mapped to the same item as you wish, and the one that appears lowest in the list will win. You may wish to test this. However, for the sake of the extra "clutter" in the UI from having lots of mappings to the same property, I would still choose the extension option that @STerjeson suggested.