Referencing “this” in Event-Based Rules

Not many people know you can pull information out about the element that an Event-Based Rule fires on, without any custom code. Let’s say I want to fire a rule on a link that looks like this, and I want to capture the domain of the link that was clicked in eVar3:

<div partner="adobe">
     <a href="http://www.adobe.com" class="partnerExit" alt="go to our partner Adobe" target="_blank">This is an example link.</a>
</div>

I would set my rule up to correctly fire on that link (with something like “a.partnerExit”), then for eVar3 I would put %this.hostname%, where “this” refers to “this thing that the rule fired on”.

I don’t have to have to do any custom code, or have a data element set up (in fact, data elements are NOT particularly useful at pulling out information specific to the element that fired an event-based rule.)

Putting this in the interface…

Would let me access…

Which would yield this…

%this.hostname% The domain of the link that was clicked www.adobe.com
%this.href% The full URL of the link that was clicked http://www.adobe.com/
%this.src% The source of the element that was clicked (works for images, not links) (Not applicable here.)
%this.alt% The “alt” value of the element that was clicked go to our partner Adobe.
%this.@text% The internal text of the element that was clicked This is an example link.
%this.@cleanText% The internal text of the element that was clicked, trimmed to remove extra white space This is an example link.
%this.className% The class of the element that was clicked (less handy in reports, but very handy for DTM troubleshooting) partnerLink

For more advanced “DOM-scraping” you may need to take to the custom code. I find jQuery often simplifies things greatly for this. For instance, in the above example, if I wanted to get the ID not of the anchor tag, but of the <div> that HOLDS the anchor tag, I could do this in the custom code:

Note that I remembered to also add it into s.linkTrackVars, since this is an s.tl beacon (DTM automatically creates s.linkTrackVars for any variables you configure directly in the interface, but can’t know which variables you are adding to the custom code section, so you must be sure to add them to linkTrackVars or linkTrackEvents yourself, or the s.tl() beacon will ignore those variables).

4 thoughts on “Referencing “this” in Event-Based Rules

  1. Hey, Thanks, this was helpful.
    But what if i have hierarchy of parent and children, for example:

    ..
    ..
    ..

    if I am trying creating an event based rule, with condition as-> “.abc” class,and using
    $(this).children(“a”).text();
    The rule is capturing texts of all it’s children. What solution would you suggest in this case?

    1. Thanks for your patience- sorry for the slow reply. WordPress didn’t let me see the example hierarchy in your comment, but I can imagine it well enough. If you’re going to use “this”, then you may need to alter what your rule fires on- so you could do “.abc a” to have it fire on anchor tags that are within an element with a class of “.abc”. That way, your “this” doesn’t apply to “.abc”, it applies to the anchor tag, and you can just reference it as “%this.@text%” in the interface, or jQuery(this).text() in custom code.

    1. When you click on the “a” element, and if you have DTM debugging turned on, do you see “SATELLITE: detected click on a” in the console? Whether or not it meets you specific rule conditions, you should see something like this anytime you click on any element on the page; DTM listens to them all. If you DON’T see that, then odds are your developers already have some javascript listening and “hijacking” that click (this is especially likely if the href is “#”). http://www.digitaldatatactics.com/examples/EBRtroubleshooting.html talks about this a bit, but often the solution is clicking the “apply listener directly to element” checkbox in the rule.
      If that isn’t the problem, you may jsut need to tweak your condition. You might be able to use something like “a[href=’#’]” as a CSS selector.

Leave a Reply to Ankita Gupta Cancel reply

Your email address will not be published. Required fields are marked *