Expand my Community achievements bar.

Join us January 15th for an AMA with Champion Achaia Walton, who will be talking about her article on Event-Based Reporting and Measuring Content Groups!
SOLVED

Direct Call Rule Trigger for one specific page

Avatar

Community Advisor

I have a "Marketo form" enabled on various site pages. I even successfully track the form submissions using the "Direct Call" Rule via launch to report in Adobe Analytics. However, for one specific page with the same Marketo Form, I want to create a separate rule in Adobe Launch to map some specific eVars for some purpose. So, I was wondering can I add the condition to the rule as per the below screenshots so that when a form gets submitted on that specific page then those specific eVars that I want to map can also get triggered. Is this is okay?

 

NOTE: in the existing rule for tracking marketo form submits the direct call trigger happens only when a successful form submission happens and then adobe launch performs the further actions. 

 

For example: If a specific page to which I want to add a set of eVars looks like 

https://www.qwe.com/about-us/events/technical-series

JyotiSharmaV_0-1736360867201.png

 

JyotiSharmaV_2-1736361279629.png

 

 

 

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Hi @JyotiSharmaV 

Path and query string should only return what's in the URL after the domain

e.g., in your example  /about-us/events/technical-series

 

or, should you have query params, /about-us/events/technical-series?someparam=somevalue

 

So yes, you can create a separate rule that does some additional tracking with other eVars, props, etc set.

You may want to exlcude these specific pages from the other rule though unless you want to send a second tracking call.

Cheers from Switzerland!


View solution in original post

6 Replies

Avatar

Correct answer by
Community Advisor

Hi @JyotiSharmaV 

Path and query string should only return what's in the URL after the domain

e.g., in your example  /about-us/events/technical-series

 

or, should you have query params, /about-us/events/technical-series?someparam=somevalue

 

So yes, you can create a separate rule that does some additional tracking with other eVars, props, etc set.

You may want to exlcude these specific pages from the other rule though unless you want to send a second tracking call.

Cheers from Switzerland!


Avatar

Community Advisor and Adobe Champion

Yep, I was just about to say that you need a condition on the original rule so that only one of the rules will trigger.. and that the "path" only looks at the path and not the full URL.

 

 

However, if I had this need, I would actually do my implementation differently....

 

An alternate option is to create some custom code Data Elements, that set a value IF the page is X, or just be empty ("") if it's not, then add those dimensions to the existing rule....

 

This way you have one rule, and the values you need for that one specific page / use will populate only when needed.

 

In Adobe, not including a dimension is the exact same as setting a dimension to an empty value... and the AppMeasurement.js won't include the dimension in the beacon if it's empty (so you don't even have to worry about it being there if there is no value).

 

 

In the Data Element, I would do something like:

var myDimension = "";

if (window.document.location.href === "https://www.qwe.com/about-us/events/technical-series"){
    // Do whatever logic you need to to get the value
    myDimension = "value";
}

return myDimension;

Note, you could also reference your "current URL" satellite value (using _satellite.getVar("urlDataElement");) rather than using "window.document.location.href" (this is completely up to you).

 

This means if you need to make any other changes to your tracking rule, you only have one rule to update, instead of two variations of the same rule.

Avatar

Community Advisor

Yeah, good point with the empty data elements.

 

This would suffice on page view call level.
Should this be part of a custom link Tracking call and should
 the additional condition change the link name that is tracked, this logic should also be placed in a data element. 

 

It really depends on the usecase

Cheers from Switzerland!


Avatar

Community Advisor and Adobe Champion

Yep, lot's of options... personally, I try to keep rules minimized where possible... even if it means the rules are a little more complex.... for me that reduces a lot of my rule management efforts.

 

But even with my solution above, that Data Element can be added to "propX" or "eVarY", etc in the set variables... the logic just exists in the Data Element itself. So linkTrackVars is covered.

 

And, IF a different link name is needed, the same logic could be used in a Data Element that sets "variation 1" or "variation 2" based on the URL, and again, that Data Element can be used right in the rule action using standard Launch features.

 

Jennifer_Dungan_0-1736365664495.png

 

Avatar

Community Advisor

Yeah, agree. Keep your property tidy and don't shy away from a line of custom code if this allows you a cleaner setup.

Cheers from Switzerland!


Avatar

Level 4

Hi @JyotiSharmaV ,

Though you can achieve this in many ways I'd choose to use the existing form submit rule with another custom code action added to it for populating the eVars you need on the specific page.

This custom code action can be populated as below,

if (window.document.location.href.split("?")[0] === "https://www.qwe.com/about-us/events/technical-series"){
    
	//populate needed eVars using respective data elements or directly from page through JS
	s.eVarX = [eVarX value];
	s.eVarY = [eVarY value];
	
	//add above populated eVars to linkTrackVars to track them on s.tl() calls
	s.linkTrackVars = s.apl(s.linkTrackVars, eVarX, eVarY);
	
}

Using this approach can be preferred because of below,

  • You get to keep the single rule for your generic and custom form tracking needs
  • Using the custom code you have more granular control on when and how to set each variable which means you can add more conditions or nest them
  • As you are setting all the variable in one place it gives you benefits like,
    • Define the conditional logic only once (unlike defining it again and again if you choose to create custom code data elements for each variable) helps in keeping the library size lighter
    • Having the custom code in one place makes it easier to update/debug when needed
  • You can order the rule actions as needed, e.g. incase override some variable values set through generic form submit set variables action with values set through custom code set variables actions and vice-a-versa

Cheers!