All posts by Jenn Kunz

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).

How to get a global “s” object in DTM

At this point in time, by default, DTM creates your analytics object (usually an “s”, as in “s.pageName”) with a local scope. This means it should be able to be referenced from any custom code blocks within DTM that are tied to your analytics tool. However, it would NOT be accessible from code on the page (or a developer console) or even non-analytics code blocks in DTM (like Third Party Tags). This can cause some pretty big problems if you aren’t aware.

sUndefined

 

 

 

To get around this, you need to define your own s object within your library. This does mean you can’t let DTM manage your library, but the change you need to make is pretty minor. You need a “Custom” configuration, and you’ll need to “Set report suites using custom code below” (since you’re essentially going to be overwriting the “s” object that DTM created, where it set your report suites for you.

configureScode

 

 

 

 

 

 

When you open the editor, add this code to the top:

s = new AppMeasurement();
if(_satellite.settings.isStaging==true)
{s.account="myDevSuite"}else{s.account="myProdSuite"}

Make sure to replace the “myDevSuite” and “myProdSuite” with the correct report suites- these should match what you have in the interface. This uses _satellite.settings.isStaging to detect the current library and set the appropriate s_code.

 

With that in place, you should be able to access the “s” object from anywhere in DTM or on your page.

UPDATE: Because of a current quirk in DTM where it looks for the H code version of your s.account, I recommend also setting this line, below the ones above:

var s_account=s.account

This should prevent any report suite confusion on s.tl beacons from Direct Call Rules and Event Based Rules.

Why do my Adobe Analytics numbers differ so much from my bit.ly stats?

Link shorteners like bit.ly, goo.gl, and t.co generally keep their own metrics for how many times users click through. Unfortunately, those numbers rarely match any other Analytic’s system, including Adobe Analytics. We’ve seen situations where the bit.ly number was as much as 10 times the analytics number. With such a big difference, both numbers look a little suspect. So, what gives?

Bots

First, there’s non-human traffic. Link shorteners’ numbers do not always account for whether the click came from a real live human being, or a bot. Goo.gle and bit.ly DO try to eliminate bot traffic, but the list they use to identify bots is likely different from the list Adobe uses (which is maintained by the IAB).
However, link shorteners are often used on twitter, and bot traffic on twitter is a whole different beast. Web bots generally crawl pages, sometimes searching for specific things. Adobe and the IAB keep a good list of the worst web-crawling bot offenders. But on twitter, the environment is more predictable (tweets, unlike webpages, can predictably be accessed/interacted with the same methods) and the actions bots perform are simpler: click, retweet, reply. This means many more “hackers” out there can create a bot with much less effort, and since they aren’t harming much, they fly under the radar of the IAB and other bot-tracking organizations.
I found a book, “TWITTER: The Dark Side – Does Bit.ly Enable a Massive Click Fraud?” (by Roman Latkovic and Robert LaQuay, Ph.D) which takes a thorough look at this issue- you can see the same research at their blog. Basically, when you start to break down individual clicks by IP and user agent, it becomes clear many bots are indeed inflating bit.ly tracking.

Javascript Disabled

Second, there’s javascript. The majority of Adobe implementations these days rely on the user firing JavaScript (some older implementations or mobile implementations may fire a hard-coded beacon, but this is increasingly rare). Link shorteners, however, run WITHOUT javascript- meaning devices that have javascript disabled would count in bit.ly but NOT in Adobe.

Lost Referrer Information

Third, bit.ly (or twitter traffic in general) may cause you to lose referrer information. Someone coming from a twitter app rather than a webpage won’t have a referrer-it may look like “Direct Traffic”. Query string parameters SHOULD always carry through, though, so make sure your shortened links include tracking codes.

Conclusion

With this information in mind, I’d be more surprised to see bit.ly numbers that MATCH an Analytics tool than I am to see wide discrepancies. What’s your experience, and what are your theories behind them?

Beacon Parser round 3

First, you’ll notice a new look and feel for both the blog and the parser- I’m trying to give it a more uniform look.

Functionally, the biggest changes in this go-around are:

  • Variables and parameter should keep a clean, sorted order.
  • You can highlight values in older beacons that don’t match the most current beacon.
  • You can change display options before submitting your first beacon.
  • Display options now include friendly names and variable descriptions, taken largely from this Adobe help article.
  • I fixed some bugs with exporting to CSV and the products string.

Setting the Products String in DTM

Enough people have asked for an example of a products string that I decided to post my example page on my server.

On the example page, you can see:

  • How to build a W3C-standard data layer object for a cart with multiple items
  • How to create a simple s.products string
  • How to create more elaborate s.products strings, including merchandising eVars.
  • What the final beacon looks like.

I hope someone out there finds it helpful!

Beacon Parser: Round One

I’ve had two major frustrations while troubleshooting and doing QA for clients lately:
1. The new POST beacons don’t split up prettily in debuggers (like Charles proxy).
2. Even if they did, it can be hard to compare beacons to each other if they don’t have the same number of variables.
So, as a pet project in the evenings, I’ve been working on a tool to solve for these problems. Today I introduce: the Beacon Parser!

I don’t consider it done yet, but it’s ready for Beta testing, perhaps. I am positive there are probably better ways to accomplish what I’ve done- I’m no development genius- but I must say i’m pretty happy with the result. I would love for a few folks to provide feedback, if possible.

Current Features:

  • If you enter multiple beacons, It aligns rows for similar variables across beacons.
  • You can export the table to a “csv” file. Note, in certain browsers (including firefox), you will need to add the “.csv” extension to the downloaded filename.
  • If your beacon includes “varName.”/”.varName” variables (clickmap, context data), it will concatenate all the currently “open” variables to output one variable/value pair:
    parserExample

Features I’m still working on (in order of ambitiousness):

  • I definitely still need to work out some bugs (see bottom of this post).
  • It doesn’t currently work great with incomplete beacons.
  • A “clear button”.
  • I’d like to sort the variables back to their original order- currently as you add new beacons that have variables the previous beacons did not, it just adds them to the end.
  • I’d like to have columns for notes on the purpose of the variable, and data quality if there’s anything clearly broken (like character limits being exceeded).
  • I’d love to connect to the Admin API and return the names of custom variables.

I’d also love to create a W3C data layer parser.

Known bugs (already). I will try to fix sometime this evening:

  • It breaks when the current or referring URL has query params in it. Kind of a big problem.
  • It struggles with some products strings.