Analysis

Stop Saying “Cookieless”

by
I created this very cheesy graphic for a blog post I wrote in… 2011. That’s right, I’ve been trying to stop cookie panic for 13 years.

(This is cross-posted from the 33 Sticks blog.)

I know we’re all sick of hearing about the “cookieless future”. As a topic, it somehow manages to be simultaneously boring (it gets too much air time) and terrifying (the marTech world is ending). But I want to discuss the problematic word itself, “cookieless”. I get that a lot of people use it metaphorically- they know that cookies as a general concept are not going anywhere; we just need a way to refer to all the changes in the industry. But I still argue the phrase is ambiguous at best, and misleading at worst. If someone brings up “the cookieless future” they might be talking about:

Technology Limitations

  • Browsers and ad blockers blocking 3rd party cookies (like Chrome will maybe-probably-someday do, and which Safari and other browsers have already been doing for years)
  • Browsers blocking or capping certain 1st party cookies (like Safari’s ITP)
  • Browsers and ad blockers blocking tracking technology (like Safari’s “Advanced Tracking Protection”, which blocks not just analytics, but GTM altogether)
  • Browsers and ad blockers blocking marTech query params like gclid or fbclid
  • App ecosystems blocking the use of device identifiers within apps (like Apple’s ATT)

OR Privacy and Consent
Depending on your jurisdiction:

  • Your users may have the right to access, modify, erase or restrict data you have on them. This applies to data collected online tied to an identifier, as well as PII data voluntarily given and stored in a CRM.
  • Your users have the right to not be tracked until they’ve granted permission (GDPR), or to opt-out of their data being shared or sold (CCPA and many others)
  • Data must be processed and stored under very specific guidelines

You’ll note under the “Privacy and Consent” list, I don’t mention cookies. That’s because laws like CCPA and GDPR don’t actually focus on cookies. CCPA doesn’t even mention cookies. GDPR is very focused on Personal Information (which is broader than Personally-Identifiable Information, or PII. Personal Information refers to anonymous identifiers like you might find in marTech cookies, but it also refers to IP addresses, location data, hashed email addresses, and so on). Again, for those in the back: CONSENT IS FOR ALL DATA THAT HAS TO DO WITH AN INDIVIDUAL, NOT JUST COOKIES. Cookies are, of course, a common way that data is tied to a user, but it is only a portion of the privacy equation.

I understand why we want one term to encapsulate all these changes in the industry. And in some ways, it makes sense to bundle it all together, because no matter the issue, there is one way forward: make the best of the data we do still have, and supplement with first-party data as much as possible. However, this conflation of technology (chromeCookiePocalypse) with consent (GDPR) has led to exchanges like this one I saw on #measure slack this week:

Q: “After we implemented consent, we noticed a significant drop in conversions. How can we ensure accurate tracking and maintain conversion rates while respecting user privacy?”

A: “Well, that’s expected, isn’t it? You will only have data from those who want to be tracked. If folks opt out, you will have less data.”

Q: “Yes, we expected a dip in conversion, however our affiliates are reporting missed orders and therefore commission discrepancies, which is affecting our ranking. They suggested API tracking and also said that since they are using first party cookies, they should not be blocked, and we should categorize them as functional“. 

Sigh. People are understandably confused. First-party cookies don’t need consent, right? Privacy just means cookie banners, right? Losing third-party cookies will mean a lot of lost tracking on my site, right? If we solve the cookie problem, work can continue as normal, right? (Answers: no, no, no, and no). 

Even people who should know better are confused. The focus on cookies has silliness like this happening:

  • Google’s “cookieless” pings that collect data even if a user has requested to not have their data collected
  • Sites removing ALL cookies from their site (talk about throwing the baby out with the bathwater, if baby-throwing took a lot of effort and resources)
  • Server-side tag management being touted as “vital for a cookieless future” (as if adding a stopping point between the user’s browser and data collection points somehow reduces the need for lasting identifiers in the user’s browser, or for consent. Server-side tag management has advantages, but it just shifts the cookie and consent issues. It doesn’t solve them. )
  • People thinking that a Javascript-based Facebook’s CAPI deployment will provide notable, sustained protection against online data loss (I have a whole other blog post about this I need to finish up)
  • Technology vendors pivoting from using anonymous online identifiers in cookies tied to one browser instance, to using online identifiers tied to personal emails and phone numbers. (One might argue this does not feel like a step forward.)
  • Agencies selling “third-party cookie audits”, to scan your site for third party cookies and help you document and quantify each one to prepare for the impending loss of data.

I want to talk specifically about this last one. This idea (that auditing your site for cookies is a key way to prevent data loss due to Chrome blocking 3rd party cookies) has been a key talking point at conferences, has been promoted by agencies and vendors selling their 3rd-party-cookie-auditing services, and is even promoted by Google’s don’t-panic-about-us-destroying-the-ad-industry documentation. 

But all the ChromeCookiePocalypse dialog- and the cookie audit recommendations- leaves out critically important context (especially if we’re talking to an audience of analysts and marketers):

  1. Between Safari, Firefox, Opera, and Brave (not to mention ad blockers), 3rd party cookies have not been reliable for some time. There is a good chance more than 50% of your traffic already blocks them, and the world continues to turn, partially because of so much mitigation that’s already been done: Adobe Analytics, Google Analytics, Facebook, Adwords, Doubleclick, etc… all already use 1st party cookies for tracking on your site (that “on your site” bit is important, as we’ll discuss in point #4).
  2. That said, we can’t pretend that if we fix/ignore the 3rd party cookie problem, then our data is safe and we can continue business as usual. Yes, 3rd party cookies are being blocked, but even 1st party cookies may be capped or limited because of things like Apple’s ITP.  Some browsers and/or ad blockers may block tracking even if it’s first-party. And there are other issues: bots are rampant on the web and most tools do a poor job of filtering them out. Browsers strip out query parameters used to tie user journeys together. Depending on your local privacy laws, you could be losing a significant portion of your web data due to lack of consent (I’ve seen opt-out rates up to 65%). All data collected online is already suspect.
    I suppose it’s better late than never, but even if Chrome weren’t changing anything, you should already be relying on first-party data wherever possible, supplementing with offline data as much as possible.
  3. A thorough audit of 3rd party cookies is not going to tell you what you need to know. I, as a manager-of-tags tasked with such an audit, can tell you your site has a Doubleclick cookie on it. I can’t tell you what strategies go into your Doubleclick ads. I can’t tell you how much of your budget is used on it. I can’t even tell you if anyone is still using that tracking. I can’t tell you from looking at your cookies how your analysts use attribution windows, or if you currently base decisions off of offsite behavior like view-through conversions. I can’t tell you, based on your cookies, if you have a CDP that is integrated with your user activation points.
    Even if the cookies alone were the key factor, a scan or a spot-check of your own site is likely to miss some of the more important cookies. If I come directly from Facebook or Google to a site, then I may have cookies that wouldn’t be there if I came directly to the site. If I’ve ever logged in to Facebook or Google within my browser, that will add even more 3rd party cookies on my site. It would be virtually impossible to audit all of those situations to find all of those cookies, but it’s THOSE cookies that matter most. Because…
  4. ...it’s the cookies that will go missing from *other* websites that will have the biggest impact. Where the ChromeCookiePocalypse gets real is for things like programmatic advertising, or anything that builds a user’s profile across sites, or requires a view into the full user journey. Accordingly, the 3rd party cookies on your own site might not be nearly as important as the cookies on other places on the web that enrich the profiles of your potential audience.

I think the reason I’m so frustrated by the messaging is because 1, I hate anything that resembles fear-mongering (especially when it includes the selling of tools and services), and 2, I’ve already seen so much time focused on painstaking cookie audits that don’t actually move an org forward. Focusing on the cookies encourages a bottom-up approach: a lot of backwards engineering to figure out the CURRENT state, rather than taking the steps towards 1st party data… steps that you should be taking regardless. Finding a 3rd party Facebook cookie on your site shouldn’t be how you find out your organization uses targeted advertising, nor should it be the reason you update your strategies. I wonder how much the push to scan websites for cookies and create spreadsheets is because that task, tedious as it is, sounds much more do-able than rethinking your overall data strategy?

If you’re afraid something has slipped through the cracks, then yes, do a cookie audit: go to a conversion point like a purchase confirmation page and look at the 3rd party cookies. Before you research each one, just note the vendors involved. Just seeing that a 3rd party cookie exists gives you a heads up that you have tracking on your site from a vendor that relies on 3rd party cookies for some part of their business model. Because if they’ve got a 3rd party cookie on your site, odds are they use that same cookie on other sites. That’s what you need to solve for: how will your business be affected by your vendors not collecting data on other sites? Don’t focus on the cookie, focus on your strategies. What technology do you have that relies on cross-site tracking? How much of your advertising budget is tied to behavioral profiling? Programmatic advertising? Retargeting? Does your own site serve advertisements that use information learned on other sites? Does your site do personalization or recommendations based on user data collected off your site? What 1st party data do you currently have that could be leveraged to fill in gaps? How can you incentivize more users to authenticate on your site so you can use 1st party identifiers more?

Talk to your marketers and advertising partners. Don’t ask about cookies. Ask what advertising platforms they use. Ask about current (or future) strategies that require some sort of profile of the user. Ask about analysis that requires visibility into what the user is doing on other sites (like view-through conversions, if you still think that’s useful, though you probably shouldn’t). Ask about analysis that relies heavily on attribution beyond a week (which is currently not very reliable and likely to become even less so.)

And, most importantly, talk to the vendors, because it’s going to be up to them to figure out how their business model will work without 3rd party cookies. Most of them will tell you what we already know, but may not be ready to make the most of: 1st party data is the key (which usually means supplementing your client-side online data with data from a CDP or other offline databases). Ask what options there are to supplement client-side tracking with 1st party data (like Meta’s Conversions API). Ask how they might integrate with a Customer Data Platform like Adobe Experience Platform’s Real-Time CDP.

I’m not arguing that we don’t need to make some big changes. In fact, I’m happy the ChromeCookiePocalypse pushed people into thinking more about all of this, even if it was a bit misguided. Technology is changing quickly. Consent is confusing and complicated. Analysts and marketers are having to quickly evolve into data scientists. It’s a lot to keep up with. But words are important, and it’s not just about cookies anymore. Welcome to the “consented-first-party-data future”*.


*I’m open to suggestions for other “cookieless” alternatives

Followup Post: Allocation in Analysis Workspace

by

I recently posted about some of the implications and use cases of using Linear Allocation (on eVars) and participation (props/events) and in my research, I thought I had encountered a bug in Analysis Workspace. After all, for this flow:

Page A Page B Page C Page D Newstletter Signup event (s.tl)
prop1
eVar1
events		 “Page A”
“Page A”
“event1”		 “Page B”
“Page B”
“event1”		 “Page C”
“Page C”
“event1”		 “Page D”
“Page D”
“event1”		 “”
“”
“event2”

I saw this in Reports and Analytics (so far, so good):

But then in Analysis Workspace for that prop, trying to recreate the same report, I saw this, where the props were only getting credited for events that happened on their beacon (none got credit for the newsletter signup):

Basically, I lost that participation magic.

Similarly, for the eVar, I saw this report in Reports and Analytics:

And in Workspace, it behaved exactly like a “Most Recent” eVar:

Again, it lost that linear magic.

Calculated Metrics to the Rescue

With the help of some industry friends (thanks, Jim Kultgen at Kohler and Seth Burke at Adobe) I learned that this is not a bug, necessarily- it’s the future! Analysis Workspace has a different way of getting at that data (one that doesn’t require changing the backend settings for your variables and metrics).
In Analysis Workspace reports, allocation can be decided by a Calculated Metric, instead of the variable’s settings. In the calculated metric builder, you can specify an allocation by clicking the gear box next to the metric in the Calculated Metric Definition:

A Note On “Default” Allocation here

On further testing, in Analysis Workspace, it seems that eVars with the back-end settings of either “Most Recent” and “Linear” allocation are treated the same: both will act like “Most Recent” with a metric brought in, and both will act like “Linear” when you bring in a calculated metric where you specified to have Linear Allocation. One might say, if you use Analysis Workspace exclusively, you no longer would need to ever set an eVar to “Linear”.

“Default” does still seem to defer to the eVar settings when it comes to Most Recent or Original (just not Linear). So in an eVar report where the eVar’s backend setting is “Original”, whether I used my “normal” Newsletter Signups event (column 2), or my Calculated one with Linear Allocation (column 3), credit went to the first page:

So, the Calculated Metric allocation did NOT overwrite my eVar setting of “Original”.

So how do I replicate my Linear eVar report?

To get back that Linear Allocation magic, I would create a new Calculated Metric, but I would specify “Linear Allocation” for it in the Calculated Metric Definitions. Then I can see that linear metric applied to that eVar (the original metric in blue, the new calculated one with linear allocation in purple) :

Note that it’s 40-20-20-20, rather than 25-25-25-25. I’ll admit, this isn’t what I expected and makes me want to do more testing. I suspect that it’s looking at my FIVE beacons (four page views, one success event) and giving that Page D double credit- one for its page view beacon, and one for the success event beacon (even though it wasn’t set on that beacon, it WAS still persisting). So it isn’t perfectly replicating my R&A version of the report, but it is helping me spread credit out between my four values.

And my participation prop?

Similarly, with the prop, when I bring in my new “Linear Allocation” calculated metrics I just set up for my eVar (in blue), I now see it behave like participation for my Newsletter Signup metric, unlike the original non-calculated metrics (in green):

…but those Page View numbers look just like linear allocation in an eVar would (2.08, 1.08, .58, .25), not the nice clean numbers (4, 3, 2, 1) I’d get for a prop with participation. At this point, I still don’t have my Content Velocity prop report, but I’m getting closer.

So how do I get my Content Velocity?

Analysis Workspace has a “Page Velocity” Calculated metric built into its Content Consumption template, which reports the same data as my Content Velocity (participation-enabled) prop did in Reports & Analytics.

 If I want to recreate this calculated metric for myself, I use the formula “Page Views (with Visit Participation)/Page Views”:

Though my friend Jim Kultgen suggested a metric he prefers:

((Page Views 'Visit Participation')/(Visits))-1

This shows you how a page contributed to later page views, discounting how it contributed to itself (because obviously it did that much- every page does), and looking at visits to that page (so repeat content views don’t count for much).

These two calculated metrics would show in an AW report like this:

Conclusion

If I use Analysis Workspace exclusively, I may no longer need to enable participation on metrics or props- I could just build a Calculated Metric off of existing metrics, and change their allocation accordingly, and that would work the same with either my eVars or my Props.

Knowing a few of these quirks and implications, I can see a future with simpler variable maps (no more need for multiple eVars receiving the same values but with different allocation settings) and the ability to change allocation without tweaking the original data set (my “Newsletter Signups” metric retains its original reporting abilities, AND I can build as many Calculated Metrics off of it as I want). I’m excited to see how Adobe will keep building more power/flexibility into Workspace!

Participation and Linear Allocation in Adobe Analytics- behavior I expected, and some I did not

by

I recently posted about some of the implications and use cases of using Linear Allocation (on eVars) and participation (props/events) and in my research, I thought I had encountered a bug in Analysis Workspace. After all, for this flow:

Page A Page B Page C Page D Newstletter Signup event (s.tl)
prop1
eVar1
events		 “Page A”
“Page A”
“event1”		 “Page B”
“Page B”
“event1”		 “Page C”
“Page C”
“event1”		 “Page D”
“Page D”
“event1”		 “”
“”
“event2”

I saw this in Reports and Analytics (so far, so good):

But then in Analysis Workspace for that prop, trying to recreate the same report, I saw this, where the props were only getting credited for events that happened on their beacon (none got credit for the newsletter signup):

Basically, I lost that participation magic.

Similarly, for the eVar, I saw this report in Reports and Analytics:

And in Workspace, it behaved exactly like a “Most Recent” eVar:

Again, it lost that linear magic.

Calculated Metrics to the Rescue

With the help of some industry friends (thanks, Jim Kultgen at Kohler and Seth Burke at Adobe) I learned that this is not a bug, necessarily- it’s the future! Analysis Workspace has a different way of getting at that data (one that doesn’t require changing the backend settings for your variables and metrics).
In Analysis Workspace reports, allocation can be decided by a Calculated Metric, instead of the variable’s settings. In the calculated metric builder, you can specify an allocation by clicking the gear box next to the metric in the Calculated Metric Definition:

A Note On “Default” Allocation here

On further testing, in Analysis Workspace, it seems that eVars with the back-end settings of either “Most Recent” and “Linear” allocation are treated the same: both will act like “Most Recent” with a metric brought in, and both will act like “Linear” when you bring in a calculated metric where you specified to have Linear Allocation. One might say, if you use Analysis Workspace exclusively, you no longer would need to ever set an eVar to “Linear”.

“Default” does still seem to defer to the eVar settings when it comes to Most Recent or Original (just not Linear). So in an eVar report where the eVar’s backend setting is “Original”, whether I used my “normal” Newsletter Signups event (column 2), or my Calculated one with Linear Allocation (column 3), credit went to the first page:

So, the Calculated Metric allocation did NOT overwrite my eVar setting of “Original”.

So how do I replicate my Linear eVar report?

To get back that Linear Allocation magic, I would create a new Calculated Metric, but I would specify “Linear Allocation” for it in the Calculated Metric Definitions. Then I can see that linear metric applied to that eVar (the original metric in blue, the new calculated one with linear allocation in purple) :

Note that it’s 40-20-20-20, rather than 25-25-25-25. I’ll admit, this isn’t what I expected and makes me want to do more testing. I suspect that it’s looking at my FIVE beacons (four page views, one success event) and giving that Page D double credit- one for its page view beacon, and one for the success event beacon (even though it wasn’t set on that beacon, it WAS still persisting). So it isn’t perfectly replicating my R&A version of the report, but it is helping me spread credit out between my four values.

And my participation prop?

Similarly, with the prop, when I bring in my new “Linear Allocation” calculated metrics I just set up for my eVar (in blue), I now see it behave like participation for my Newsletter Signup metric, unlike the original non-calculated metrics (in green):

…but those Page View numbers look just Despite clearly remembering learning about it my first week on the job at Omniture in 2006, I realized recently that I did not have a lot of confidence in what participation and linear allocation would do in certain situations in Adobe Analytics. So I put a good amount of effort into testing it to confirm my theories, and I figured I’d pass along what I discovered.

First, the Basics: eVar Allocation

You may already know this part, so feel free to skip this section if you do. Allocation is a setting for Conversion Variables (eVars) in Adobe Analytics, with three options:

Let’s take a simple example to show what how this effects things. Let’s say a user visits my site with this flow:

Page A Page B Page C Page D Form Submit- Signup
s.eVar5=”Page A” s.eVar5=”Page B” s.eVar5=”Page C” s.eVar5=”Page D” s.events=”event1″

Most Recent (Last)

Most eVars have the “defaultiest” allocation of “Most Recent (Last)”, meaning in an event1 report broken down by eVar5, “Page D” would get full credit for the event1 that happened, since it was the last value we saw before event1. So far, pretty simple.

Original Value (First)

But maybe I want to know which LANDING page contributed the most to my event1s (there are other ways of doing this, but for the sake of my example, I’m gonna stick with using allocation). In that case, I might have the allocation for that eVar set to “Original Value (First)” so then “Page A” would get full credit for this event1, since it was the first value we saw for that variable. If my eVar is set to expire on visit, then it’s still nice and straightforward. If it’s set to never expire, then the first value we ever saw for that user will always get credit for any of that user’s metrics. If it’s set to expire in two weeks, then we’ll see the first value that was passed within the last two weeks.

This setting is frequently used for Marketing Campaigns (it’s not uncommon to see s.campaign be used for “Most Recent Campaign in the last 30 days” and then another eVar capture the exact same values, but be set to “Original Campaign in the last 30 days”).

Linear Allocation

If I’m feeling a bit more egalitarian, and want to know ALL the values for an eVar that contributed to success events, I would choose linear allocation. In this scenario, all four values would split the credit for the one event, so they’d each get one fourth of the metric:

(Though it may not actually look like this in the report- by default it would round down to 0. But I’ll talk about decimals later on).

So, that’s allocation.

Then what is participation?

Participation is a setting you can apply to a prop, so that if you bring a Participation-enabled metric into the prop’s report, you can see which values were set at some point before that event took place. Repeat: to see participation you must have a prop that is set to “Display Participation Metrics”:

And the metric you want to see needs to have participation enabled (without this, in the older Reports and Analytics interface, that event won’t be able to be brought into the prop report):

Unlike linear allocation for an eVar, participation for a prop means all the values for that prop get full credit for an event that happened. So, given this flow:

Page A Page B Page C Page D Form Submit- Signup
s.prop1=”Page A” s.prop1=”Page B” s.prop1=”Page C” s.prop1=”Page D” s.events=”event1″

You would see a report like this, because each value participated in the single instance of that event:

New Learnings (for me): Content Velocity

One thing these settings can be used for is measuring content velocity: that is, how much a certain value contributed to more content views later on. For instance, if I have a content site, and I want to know how much one piece of content tends to lead to the reading of MORE content, I might use a participation-metric-enabled prop with a participation-enabled Page View custom event, or I might use an eVar with linear allocation against a Page View custom event (whether or not the event has participation enabled doesn’t matter for the eVar). For my test, I did both:

Page A Page B Page C Page D
s.prop1=”Page 1″
s.eVar1=”Page 1″
s.events=”event1″		 s.prop1=”Page 2″
s.eVar1=”Page 2″
s.events=”event1″		 s.prop1=”Page 3″
s.eVar1=”Page 3″
s.events=”event1″		 s.prop1=”Page 4″
s.eVar1=”Page 4″
s.events=”event1″

The prop

The prop version of this report would show me that Page 1 contributed to 4 views (its own, and 3 more “downstream”). Whereas Page 2 contributed to 3 (its own, and two more downstream), etc…

The eVar

Alternatively, the eVar would show me some thing pretty odd:

Those weird numbers don’t make sense on this small scale (how could 0 get 6.3%?), because it is rounding, and not showing me decimals. If I want to see the decimals, I can create a really simple calculated metric that brings in my custom Page View event (event1) and tells it to show decimals:

The report then makes a little more sense and show us where the rounded numbers came from (and how Page 4, with “0” Page Views, got 6.3% of the credit), but may still seem mysterious:

Those are some odd numbers, right? Here’s the math:

 Value Credit Why?   Explanation
Page 1 2.08 1+0.5+0.33+0.25 It got full credit for its own view, then half the credit (shared with page 2) for the event on Page 2, then a third of the credit (shared with Page 2 and Page 3) on Page 3…
Page 2 1.08 0.5+0.33+0.25 It only got half credit for the event that took place on its page (shared with Page 1), then a third of the credit (shared with Page 1 and Page 3) on Page 3, etc…
Page 3 0.58 .33+.25 It only gets a third of the credit that took place on its page, and a quarter of the credit for the fourth page.
Page 4 0.25 0.25 The event that happened on this page is shared with all four pages.

Crazy, right? I’m not going to tell you which an analyst should prefer, but as always, you should ask the question: “What will you DO with this information?”

What happens when multiple values appear in the same flow?

Let’s say the user does something like this, where they hit one value a couple page views in a row (Page B in this example), or they hit a value 2 separate times (Page A in this example):

Page A Page B Page B
(again)		 Page C Page D Page A
(again)		 Conversion event
prop1
eVar1
events		 “Page A”
“Page A”
“event1”		 “Page B”
“Page B”
“event1”		 “Page B”
“Page B”
“event1”		 “Page C”
“Page C”
“event1”		 “Page D”
“Page D”
“event1”		 “Page A”
“Page A”
“event1”		 events=”event2″

For the prop, it’s pretty straightforward. This will look like 6 event1s, where Page A gets value for all 6, and Page D gets credit for just 2 (itself, and the Page A that came afterwards):

For the eVar, it gets a little more complicated (I added in a calculated metric so you can see the decimals). Page A (accessed twice at separate times) got double credit for the conversion (which I might have predicted), but Page B (accessed twice in a row) ALSO gets double credit for the conversion (which I didn’t predict, probably because I’m too used to thinking in terms of the CVP plugin):

Caveats

A couple things to be aware of:

  • Settings for participation and allocation don’t apply retroactively- you can’t apply them to existing data. If you want to start using it, you need to change your settings and you’ll see it applied to future data. However, this can mess with existing data, so be careful.
  • Analysis Workspace does some unexpected behavior for both participation and allocation. I’ll have a followup post on that.

Conclusion

Both participation and linear allocation aren’t used often, but they can uniquely solve some reporting requirements and can provide a lot of insight, if you know how to read the data. I hope my experimentation and results here help make it clearer how you might be able to use and interpret data from these settings. Let me know if you have other use cases for using these settings, and how it has worked out for you!like linear allocation in an eVar would (2.08, 1.08, .58, .25), not the nice clean numbers (4, 3, 2, 1) I’d get for a prop with participation. At this point, I still don’t have my Content Velocity prop report, but I’m getting closer.

So how do I get my Content Velocity?

Analysis Workspace has a “Page Velocity” Calculated metric built into its Content Consumption template, which reports the same data as my Content Velocity (participation-enabled) prop did in Reports & Analytics.

 If I want to recreate this calculated metric for myself, I use the formula “Page Views (with Visit Participation)/Page Views”:

Though my friend Jim Kultgen suggested a metric he prefers:

((Page Views 'Visit Participation')/(Visits))-1

This shows you how a page contributed to later page views, discounting how it contributed to itself (because obviously it did that much- every page does), and looking at visits to that page (so repeat content views don’t count for much).

These two calculated metrics would show in an AW report like this:

Conclusion

If I use Analysis Workspace exclusively, I may no longer need to enable participation on metrics or props- I could just build a Calculated Metric off of existing metrics, and change their allocation accordingly, and that would work the same with either my eVars or my Props.

Knowing a few of these quirks and implications, I can see a future with simpler variable maps (no more need for multiple eVars receiving the same values but with different allocation settings) and the ability to change allocation without tweaking the original data set (my “Newsletter Signups” metric retains its original reporting abilities, AND I can build as many Calculated Metrics off of it as I want). I’m excited to see how Adobe will keep building more power/flexibility into Workspace!

Find the total number of values in an Adobe Analytics Variable Report

by

“How do I know how many rows/unique values are in my eVar report?”
I hear this question fairly often, and since the answer isn’t currently extremely straight-forward, I figured I could walk through the solution here. So let’s say you have a report with many pages:
reportPagination
Rather than trying to get to the last page of the report somehow to see how many row numbers there are, you can find out about the number of unique values in the report using the Row Count calculated metric.
To set this up, go to add a metric to the report, then “Add” to get to the Calculated Metric wizard:
addCalcuatedMetric

Give the metric an intuitive name, like “Report Rows” or “Unique Reported Values”, then search in the formulas for “Row Count”:
rowCount

Drag “Row Count” over to the Calculated Metric Definitions, and save. That’s all there is to it!

RowCountCalc

Now you can have that as a metric in your report. For whatever reason, it doesn’t always show nicely if it is the ONLY metric selected, so I recommend having at least one metric (like visits) alongside it as well. It doesn’t make a ton of sense in the report, line-by-line: every line will show the same number, and that number represents the aggregate number of values in the report. So in the below, I can see this particular report has 140 unique rows/values in it:
RowCountReport

I do believe in the future, a simpler way of doing this may be a bit more built in, but for now, here is a relatively easy way to get a count of values for a report!

How to approach Product Finding Methods

by

Product Finding Method (PFM) is a valuable custom report used by online retailers to tie Cart Adds and eventual Revenue to how users found the product. Unfortunately, these reports are often poorly configured or misunderstood. It is one of the best use cases for using the Merchandising setting on an eVar, but Merchandising, as a concept, is one of the more complicated topics in implementation.

Primer on Merchandising

In order to tie that PFM value to an individual product, and not the overall visit or visitor, we need to use Merchandising. And since we may not know the eventual product at the time that we know the finding method (for instance, if a user is using internal search, at the time we know they are searching, we don’t know what product they’ll eventually land on), we need to use Conversion Syntax- meaning we set it like a typical eVar (instead of in the products string) but have to configure at what point that eVar should be tied (or “bound”) to a product. Take the following user experience into consideration, where eVar5 is used for Product Finding Methods:

PFMflow

In the above, if I did NOT use Merchandising, my report might look like this, where External Campaign gets credit for everything up until it gets overwritten by Internal Search– at which point Internal Search gets credit for everything, including the entire Purchase event.

PFMnoMerchReportIf I DO use Merchandising, the External Campaign gets credit for whatever happens to the product it was bound to- in this case, the Blue Wug. Then Internal Search gets bound to the Red Wug, and gets credit for whatever happens to the Red Wug product:

PFMwMerchReport

We have to be very careful with the binding events (the event that tells Adobe to take whatever value we currently have floating around for that eVar and stick it to the current product), though- merchandising eVars won’t get credit for anything that happens if they are not bound to any product, or if that product isn’t currently present. For instance, in the example above, if you pulled in Internal Searches as a metric in that report, you’d see no PFMs were getting credit for the Internal Search event- even though eVar5 is set on the same page as our search event. That’s because that “Internal Search” value for eVar5 is waiting until a “binding event” to attach it to a product before it will get credit for any metrics, and the “External Campaign” value for eVar5 only gets visibility into things that happen to the product it’s bound to (Blue Wug). No products on the Internal Search page means Conversion-Syntax Merchandising eVars get no credit for the Search event.

How to Plan Your Product Finding Methods

To design your PFM solution, start by thinking of the different ways a client can add an item to their cart. We’ll call these “add to cart location” and give that its own eVar. Typical scenarios are:

  • product details page
  • quick view
  • from wishlist
  • from order history
  • recommendation/cross sell modules

Next, figure out all the ways a user could get to any of those above scenarios. These are Product Finding Methods and should get their own eVar. Typical PFMs include:

  • internal search
  • external site (referrerss and natural search)
  • external campaigns (that take the user directly to the PDP)
  • internal promotion (eg, homepage hero banner)
  • browse (naturally navigating through the menu or breadcrumbs)
  • cross-sell
  • recommendations
  • wishlist
  • order history 

You’ll notice some of your cart add locations may also be product finding methods- that’s ok. Note that Products Detail Page is NOT a PFM- the Product Details page is specific to the product, which is the thing being found not the thing doing the finding.

Both of these eVars will need to be set up for Merchandising (this is set in the Admin console>Report Suites>Edit Settings>Conversion>Conversion Variables). For the Add to Cart Location eVar, since we know the product at the time we know the add to cart location, you can use “product syntax”.

eVar4PFM

This is preferable because it leaves little room for error and has the easiest configuration. Let’s say I’ve set eVar4 to be my “Add to Cart location” eVar. At the time my user adds any item to their cart, I would set eVar4 (often, you can just set it to the current page’s page type):

s.products=";sku1;;;;eVar4=PDP"
s.events="scAdd"

But for Product Finding Method, you often don’t know what product the value for our eVar will eventually bind to, so we need to set it to conversion syntax, and we need to carefully consider which events should bind the current PFM value to the current product. Generally, Product View (ideally a custom event, not prodView) and Cart Add suffice as binding events.

eVar5pfm

DO NOT set to bind on ALL events, as many events happen on your site where your PFM eVar doesn’t have a desirable value.

Next, to implement, we need to figure out where to set each of our PFM values. If you’re using a tag management system like DTM, you can often just piggy back on existing rules for many of your finding methods, but others may need to live in global logic (like in your s_code). See below for a possible configuration.

internal search Set on internal search results page
external site Set in global logic- if no other PFM is present, and the user came from a domain other than your own
external campaigns Set in global logic, if s.campaign is set
internal promotion Set in global logic, if internal campaign eVar is set (or internal campaign query string parameter is present).
browse Set on all Product List Pages and Category pages
cross-sell Set when user clicks or clicks through on a cross-sell module
recommendations Set when user clicks or clicks through on a recommendation module
wishlist Set on Wish List page
order history Set on Order History page

Some folks manage PFM entirely in their s_code or in their (global DTM tool settings) based on whether other variables have been set (“if internal search term eVar has a value, set eVar5 to ‘internal search”‘). For instance, one client has something similar to this, in addition to setting their PFM eVar directly on certain pages (like their List Pages and Category pages, or certain microsites):

//easy way to get just the hostname of the referring site
   var a=document.createElement('a');
   a.href=document.referrer;
   s.refDomain=a.hostname;

if(!s.eVar5){ //if PFM not currently set on the page
   if(s.campaign){s.eVar5="campaign"} 
   else if(s.eVar10){s.eVar5="internal search"}
   else if(s.eVar23){s.eVar5="recommended product"} 
   else if(s.pageName=="My Account>Wishlist"){s.eVar5="my wishlist"}
   else if(document.referrer==""){s.eVar5="direct or bookmarked"}
   else if(s.refDomain.indexOf("mydomain.com")==-1){s.eVar5="external site"} 
 }
   else if(s.eVar15){s.eVar26="internal campaign"} 
}

Conclusion

Hopefully, this gives some ideas and examples for how to get valuable reporting on how users are finding and purchasing products on your site. I’d love to hear about potential scenarios or solutions I’ve missed!

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

by

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

Using Google Analytics Settings to Properly Identify Pages

by

This year, I’ve been involved in many Google Analytics implementations and audits, and there has been a recurring theme around misunderstood GA Configuration Settings, mostly regarding how a page is identified. For instance, one recent client of mine had a 350-page site. But because of missed configuration settings, those 350 pages were showing up as literally 28000 URIs! Can you imagine pulling a report on any given page of that site? So to clear the air and hopefully save some GA users out there from future headaches, here are 3 quick ways to use GA Configuration to properly identify your pages:

1. DEFAULT PAGE DOES NOT MEAN “MY DEFAULTIEST PAGE”

The default page setting is used whenever a page URI ends in a trailing slash without specifying a file name- for instance, if you used this setting to specify that “index.html” is your default file name, “example.com/”and “example.com/index.html” would merge into just “example.com/index.html” in your content report, making analysis on that single page much easier.

Unfortunately, the name of the setting is misleading and tempts people into entering what they consider the “default page” of their site: their home page. But if you enter “http://www.example.com/index.html” as your default page, the real result would be that any page that ends in a trailing slash will have the full home page URL appended to it:

www.example.com/folder/

would become this in the reports:

www.example.com/folder/http://www.example.com/index.html

This is obviously not desirable, so please do not put your full home page URL as your “Default Page”. If you have a site that sometimes uses index.html or index.php, then you may want to specify THAT as your default page, so all pages with a trailing slash would consistently have index.html appended to them. Otherwise, leave the setting blank.

2. SO WHAT DO I DO ABOUT THOSE TRAILING SLASHES?

The default page setting cannot be used for what most people WANT to use it for- to standardize whether or not a page ends with a trailing slash. If you give in to the temptation to simply put a “/” in this setting, then “folder/” and “folder” wouldn’t merge together as desired- rather, “folder/” would become “folder//”, and “folder”would stay the same (remember, the setting only looks at which pages have a trailing slash, then appends the setting value to it).

If you would like to have all trailing slashes removed as the standard, so that example.com/folder/ and example.com/folder would appear as the same line item in the Content report- and who wouldn’t want that?- you will need to set up a custom filter that removes all trailing slashes:

GApages

Field A -> Extract A should be set to “^/(.*?)/+$”
Output To -> Constructor should be set to “/$A1”

Please note, much to my chagrin, such a filter would prevent your profile from being eligible for the not-filter-friendly Real Time Analytics(for now), but I promise this isn’t as big a deal as you might think it is, though I’ll save my reasoning for the unimportance of “real time” analytics for another blog post.

3. EXCLUDE PARAMETERS!

Most GA implementations I’ve seen have at least a few query string parameters excluded, but I don’t think I’ve seen anyone get it “just right” yet (admittedly, my level of nitpickiness may be a tad unrealistic). The problem with not excluding all non-content-identifying parameters is that parameters will cause one page to show up as separate items in the content report. For instance, if I want to report on how many page viewspromotions/springlanding.html got, I might need to pull the following 3 pages:

promotions/springlanding.html
promotions/springlanding.html?secured=true

AND

promotions/springlanding.html?type=4

Into my reports, to report on only one piece of content. This isn’t the end of the world; using filters in my reports I can usually get the info I need, though it does make trending harder. But it’s such an easy fix!

To see which query parameters might have escaped your settings, go to your Top Content report and do a search for “?”. If there are a variety of those pernicious params in there, you may want to use an advanced filter to filter them out one at a time, to be sure you’ve got them all. Now you have a handy list of parameters you can take to your configuration settings for exclusion. If you want to track one of the parameters, but not necessarily in your content report, don’t forget you can always use a Profile Filter if you want to extract a query parameter and put it into another field, like a user defined variable, or just clean up parameters in general.

Be careful to not exclude parameters that actually have importance in identifying content. For instance, a products page may have a ?sku=12345 that specifies which product is being viewed- this is a rather critical piece of information for some types of analysis, and should not be excluded.

Please be aware that users can add whatever parameters they want to your URLs, so you will never have full control here. Tools like Google Translate like to wreak havoc on URIs, but generally account for a very small percentage of page views.

Cleaning up your Content Report is an easy quickwin- it doesn’t take a lot of effort and can make analysis much easier. For questions about identifying content in Google or SiteCatalyst, contact me on twitter- @Jenn_Kunz.

Campaign Tracking Tips and Tricks for Omniture SiteCatalyst

by

The standard Omniture Campaign reporting offering, based solely on a query string/tracking code pair, is pretty solid: campaign reports and all the possible classifications, paid/natural search detection and reporting, and marketing channel reporting, managed from right there in the SiteCatalyst admin console. But over time we’ve found some tips and tricks that can maximize the value of your campaign tracking efforts.

All of these tips rely on granular but intuitive tracking codes, which your s_code grabs automatically out of a query string parameter. If you do not have a well-founded system for setting your tracking codes, then that should be your focus before expanding your campaign reports. Assuming you have your marketing efforts well identified, here are some ideas to implement:

TIP #1: CUSTOM CAMPAIGN CLICK-THROUGHS

Out of the box, SiteCatalyst has the “click-throughs” metric in any campaign report, which is essentially the same as “instances” in any other conversion report. The problem is that you cannot pull your campaign click-throughs as a metric into non-campaign reports- for instance, into a campaign landing pages report, or a breakdown for any other eVar that lasts between sessions or is set on a campaign landing page. A common need is to see Campaign Click-throughs in a conversion funnel:
campaignClick-throughs

For this reason, many of my past clients have implemented a “custom” campaign clickthrough event, which they then have full control over.

The code for this is simple. I recommend using the Append List plugin (s.apl) to ensure the custom event does not overwrite any other events on the page. In this example, event3 has been set aside and named “Custom Campaign Click-throughs”, and the append list plugin code is included in the plugins section:

s.campaign=s.getQueryParam(‘cid’);
if(s.campaign){s.events=s.apl(s.events,’event3′,’,’,1)};

TIP #2: GRANULAR, CLASSIFIED TRACKING CODES WITH A MARKETING CHANNEL PREFIX

This isn’t so much a tip as it is a best practice. While generally the recommendation has always been to just have a granular tracking code and all information could be uploaded afterwards using SAINT classifications, you might save yourself a lot of headache by including a marketing channel identifier in each tracking code. SAINT is a wonderful tool, but classifications cannot be used to define the (fantastic) Marketing Channel reports. So instead of relying solely on classifications to specify that tracking code “2364FS” was an email campaign, turn the tracking code into “em-2364FS”. Not only does this make it easy to filter your tracking codes report, but you can also then set up a Marketing Channel processing rule that specifies that any tracking code that beings with “em” should go into the “Email Campaign” channel:

marketingChannel

What? You haven’t set up your Marketing Channel reports? Well, get on it! It doesn’t take long, this blog post will wait.

TIP #3: CAMPAIGN LANDING PAGE PATHING

I’ll admit, of all the tips listed here, this is my favorite. The standard pathing reports are wonderful but not a lot of help for marketers. Campaign Landing Page Pathing uses a pathing prop to show how campaigns play into paths that users take through the site. Any time the s.campaign variable is set, it is appended to the pageName and put into a prop that has pathing enabled (“Promo Landing Page: em1435”). For all other pages, just the pageName is set:

if(s.campaign){s.prop11=s.pageName+": "+s.campaign}
 else{s.prop11=s.pageName};

As a freestanding page views report, I’ll admit the data is nearly useless- a jumble of campaigns and pageNames. BUT, once viewed in a pathing report, you can now see for each campaign and landing page, what next steps a user took. You might see paths that look like this:

Landing Page A: em12543 > Page B > Page C > Exit

You can now create Fall-Out reports based on particular campaigns. You could also see a next page flow report like this, showing the full range of possible paths users are taking from a campaign landing page:

campaignNextFlow

Is your campaign taking your users somewhere you didn’t expect? Is that something you can capitalize on?

You can hit two birds with one stone and use the same logic to also set a “Campaign Landing Page” eVar, if you want to see how individual landing pages contribute to conversion (see the final code of this post for an example).

Please note, this kind of trick becomes less necessary in SiteCatalyst 15 because you can now segment your pathing reports based on campaigns, but it would still be useful if you wanted to compare campaigns to each other quickly without setting up a segment for each.

TIP #4: CAMPAIGN CROSS-VISIT PARTICIPATION

Campaign Cross-visit Participation, also known as “campaign stacking”, has been well covered elsewhere on the web, so I won’t go into too much detail, but no campaign “tips” post would be complete without it. The Marketing Channel reports can show you First and Last Touch, but not much in between. Using the crossVisitParticipation plugin, you can see all of the different campaigns a certain user touched before accomplishing a certain event. Using this plugin for my tracking codes, I could do a report filter for one specific tracking code and see how other tracking codes contributed to it leading to a conversion:

CVPcampaign

The code looks like this:

s.eVar26=s.crossVisitParticipation(s.campaign,'s_cpmcvp','90','5','>','')

While this plugin is wonderful for campaigns, the possible uses of it are limitless- any time you want to see the “path” a user takes through the values of any of your variables, and how that path affects conversion.

ALTOGETHER NOW

If I were to use all of the above tips and standard best practices, my final code might look something like this:

/* Campaign tracking */
 if (s.getQueryParam('cid'))
 {s.campaign=s.getQueryParam('cid');                                         //capture campaign ID
 s.events=s.apl(s.events,'event7',',',1)   ;                                 //custom Campaign Clickthroughs
 s.eVar26=s.crossVisitParticipation(s.campaign,'s_cpmcvp','90','5','>','');  //campaign "stacking"
 s.eVar24=s.prop11=s.pageName+" : "+s.campaign ;                             //campaign landing page eVar and pathing prop
 s.eVar25=s.campaign=s.getValOnce(s.campaign, 'cid_cookie', 0);              //campaign eVar with original allocation
 }else{s.prop11=s.pageName}  ;                                               //campaign landing page pathing

The final result is a set of marketing reports that paint a fuller picture of campaign behavior on your site.

Code for the Append List and GetValOnceplugin can be found in the Help section of SiteCatalyst, under Product Documentation > Implementation > Plugins. Contact your friendly implementation consultant if you need information about implementing Cross-Visit Participation.

Omniture Form Analysis Pitfalls – How to Avoid and Optimize

by

There is an Omniture plugin, Form Analysis, that will automatically flag which form field a user last touched before abandoning a form. Sounds great, right? This post, which does a great job of going over setting up the plugin, even claims the plugin will make you an office hero! The problem is, this plugin is inherently Evil. And not the good kindof evil. We’d like to tell you how to avoid the evil and keep your Form Analysis on the side of Good.

This plugin is notorious for being implemented incorrectly, and the implications go beyond just one report not working. Since the plugin sends a custom link call (s.tl()) each time a user abandons a form, it has the potential to eat up your secondary server calls (which you pay Omniture for). A recent client of mine has accidentally set one extra secondary server call on every single page view since 2008 because of this plugin. Sending two server calls (one with the click of a link and one on the load of the next page) so close together has been known to cause problems- every once in a while, the two calls compete and only one makes it through to Omniture, decreasing data accuracy. Worst case scenario, the plugin can actually break your form.

And what bugs me most- and this is in no way the fault of the plugin- is that folks use this as a safety crutch: they know they should optimize forms, so they put effort into setting up form tracking, then pat themselves on the back for  job well done. But, feeling comfortable that the data is there, they don’t take it to the next step and actually optimize their forms.

In this situation, you’d be better off skipping the plugin and go right to the “optimize your form” step by using your God-given intelligence. Use common sense. Think like a user: keep forms simple and easy to use. Simply running a plugin or tool will do nothing to improve your forms- remember, brains are more important than tools.

Don’t get me wrong, the plugin has much potential to do good. You just have to put some thought into it. Educate yourself on using this plugin and you can get great value out of it. To help you, here are some implementation pitfalls to avoid:

1. POTENTIAL PROBLEM: TRACKING THE WRONG FORMS

The configuration of the plugin includes two critical variables:

s.formList=””
s.trackFormList=false

When trackFormList is set to true, it will only track forms specified (using the form’s HTML “name” attribute) in the formList (if formList is blank, then nothing will be tracked). So far so good. When set to false, the plugin will track every form on your site that is NOT specified in the formList. This includes:

  • User login forms (even if they are on every page)
  • Some asp.net “forms” that are not actually user forms
  • Find-a-location-near-you and other single-field forms
  • CAPCHAs
  • And, the biggest culprit: Internal Search forms

So if a user hits a page with an internal search form field without hitting the search “submit” button, that’s one server call to Omniture letting you know a “form” was abandoned. If each page has that internal search field, that’s one server call for every page view on your site. Not only is that information useless to you, it has potentially terrifying billing implications, depending on your contract.

SOLUTION: S.TRACKFORMLIST=”TRUE”

My suggestion? ALWAYS have trackFormList equal to “true”. This will require you going through your site and finding the forms that matter most. Focus on one or two key forms on your site. This isn’t just a work-around to get the plugin to work- it’s a great idea for focusing your analysis efforts and avoiding the Data Squirrel pitfall.

2. POTENTIAL PROBLEM: THE PLUGIN RELIES ON YOUR FORMS BEING SET UP “JUST RIGHT”

If you do not have the “name” attribute in the HTML <form> tag, the plugin won’t work. And if you do have names but they look like “form134″, it probably won’t have much meaning for you in the reports. And if every form on your site has the same name, the report will be useless. Same goes for form field/input names.
On another note, if your form script references the “this” object at all, the plugin may break your form, or vice versa. Oops. The only way around it is to remove the plugin, or remove the references to “this”.

SOLUTION: UPDATE FORM HTML

I’m afraid there is no quick javascript fix here: if you want to automate form abandonment tracking using this plugin, you may have to manually change the “name” attribute of the HTML forms. BUT, if you are focusing on only your 1-2 key forms, as mentioned above, the changes to your HTML should be minimal.

3. POTENTIAL PROBLEM: CAN PAINT INACCURATE PICTURE OF WHICH FIELD IS “GUILTIEST”

The plugin doesn’t tell you which field was the “turn-off”: it tells you the last field touched, which may be counter-intuitive. For example, on the right is what my form looked like when the user abandoned:

Our friend Mal only made it through the 4th field- the one with the name “email”. The plugin would report this as:

pageName:formName:email:abandon

Which might make one think the “email” field was to blame for the abandon, when in truth, he filled out that field successfully and was (presumably) “turned off” by the FOLLOWING field, asking for him to confirm his email- he’s much too busy to waste time by entering the same information twice.

SOLUTION

One can get around this by 1)educating users of the report on what the data means (which you should be doing anyways) and/or 2) creating a classification report that says the FOLLOWING field for each item. Either way, please be aware that a report can only give hints- it cannot actually tell you what the user was thinking when they left the form or if they had looked ahead further in the form and were “turned off” by a later field.

Which brings us back to the idea that your brain is a critical part of making this plugin valuable. If you have a form on your site, now is a great time to optimize it. We’ve removed the roadblocks; what’s stopping you?

Tracking ~ Why Business Intelligence leads to User Benefits

by

A few weeks ago, I received an email from a respected consumer watchdog group campaigning for support for two online privacy bills currently being discussed in Congress. Here’s a sample of what it contained:

“Hidden ‘cookies’ in your computer that track your Internet movements and record what you buy online. Smartphones that secretly log the places you go. Even your personal information on Facebook may have been accidentally leaked to advertisers, according to media reports…”

“…The latest bill from Sen. Rockefeller would require companies to honor your decision if you do not want to be tracked online. And it would put the full force of the law behind your decision, so tracking companies would be held accountable if they go against your wishes.”

cookies

DATA LEAKS & CONSUMER CONFIDENCE

Things like Facebook data leaks and the recent Sony data security fiasco should be taken very seriously. Users should be able to feel confident that their personal information is secure. But this email, along with some of the legislation it references, mentions online tracking cookies together with major security breaches despite the fact that they are two VERY separate issues. *Ironically, the links in the email take you to a site that uses Google Analytics tracking cookies.*

GOVERNMENT INTERVENTION

The first bill, proposed by McCain/Kerry, seems to me to make a lot of sense: if a website is collecting personal information, it has a responsibility to the users to notify them and keep their information secure and private. This falls well in line with how the Web Analytics industry treats data (see the Google Analytics or Omniture Terms of Service, or the Web Analytics Association’s Code of Ethics).

Another piece of legislation, led by Senator Rockefeller, is on the floor right now: a “Do-Not-Track” bill that will legislate a user’s ability to opt-out of having any of their online activity tracked. Along with this bill comes much propaganda like the above-mentioned email, scaring people into thinking technology that they don’t understand must be harming them.

I’m not saying that users should not be able to opt-out of online tracking. Most web analytics vendors already have an opt-out for the data mentioned above and most websites already have a privacy policy detailing what is being tracked. The industry is already self-regulating things like opt-outs- I have yet to hear of a case where a user’s request to opt-out has not been respected. Odds are, you go about your online business every day without ever looking for opt-outs and privacy policies because you don’t feel threatened until politicians bring it up.

THE PROBLEM WITH GOVERNMENT INVOLVEMENT

The problem with the legislation and the information going out with it is that it lumps all kinds of tracking together, from security leaks of personal data (very bad), data-mining and sharing (potentially bad) to web analytics tracking (good). Web Analytics tracking, when done in accordance with industry standards, leaves practically no room for harm to the user and so much room for benefit for the user, but by legislating it and scaring the public with mixed-up information about it, it may lead internet users to opt-out of services that are actually beneficial to them.

Let’s take a look at just how “evil” these tracking cookies are and what information they store. On my blog currently (unless you have blocked it) I have set an Omniture cookie that may look something like this:

exampleCookie

The “value” (what the cookie contains) is just a string of arbitrary letters and numbers that serve no purpose other than to identify the user from page to page. “User afb5ced3bc5c8c3767728316b1db17f2 came in on the Google keyword ‘blue wugs’ and went from the home page to a content page then left the site.” If I had a retail site, I might use this cookie to track what items were purchased and how much revenue I generated, so that I could tie it back and see which marketing efforts are returning value.

CONSUMER AND USER BENEFITS

Every internet user should WANT this kind of tracking on them. It’s like voting by secret ballot: every time you click (or don’t click) on an item, you are submitting an anonymous vote for how the website could be better.

These are the kinds of messages you are anonymously sending to the website you are on, without even knowing about it, when you are tracked:

  • “It took me 18 clicks to get to the content I was looking for. Not cool. Please streamline your website.”
  • “Your advertising partner’s “interactive media” ad on your homepage is so annoying that I could only handle being on your site for two seconds before I closed my browser. You may make money off of hosting that ad, but you just lost my business.”
  • “Your video got really boring about 2 minutes into it. Best keep it short and sweet.”
  • “That article was fantastic, I clicked your share button to pass it along! Please make more content like that!”
  • “Asking me to verify my email address for a third time on your 16-field form probably wasn’t a great idea. You won’t find me hitting the submit button on your form until you ask for less info.”
  • “I can’t find the Technical Support information I needed online. Instead, I’m going to have to call one of your employees, wasting both my time and your staffing budget.”
  • “I came from a Google advertisement on one of my favorite blogs and ended up finding just what I needed. Thanks!”

When these pieces of feedback are looked at in aggregate- thousands of users all trending one way or another- Web Analysts not only can see what ways to improve their site but also where they should spend marketing dollars.

TARGETING VS RELEVANCY

Much of the current legislative hullabaloo is around targeted marketing efforts. Targeting is when websites use tracking technology (usually something beyond basic web tracking) to automatically present a user with content that is particularly relevant to them based on information that the website has learned about that user. For instance, on Facebook I just saw this ad:

Either highly coincidental, or Facebook has learned (probably from my user profile where I state my profession as a web analytics professional) that I have an email-based job and that I am obsessed with measuring/analyzing data. This is targeted advertising and it comes in many forms. Once you get past feeling mildly creeped out (it helps to remember it’s all anonymous and automated), targeted advertising benefits you in all sorts of ways.

All internet users want online marketers to succeed, whether they are aware of it or not. The existence of (and free access to) the sites we know and love relies on successful marketing. I know no one loves an internet cluttered with ads, but I’m pretty sure we’d hate it even more if it were ad-free with the caveat of having to pay for each site we visited. The more relevant the ads can be to the users, the more successful they are- meaning less ads are needed to keep the internet afloat. Targeting not only helps keeps the internet free it makes the internet more relevant to users.

With web analytics tracking technology as it is right now, you can send an online marketer a message that their ad is annoying or ineffective by simply not clicking on it. Marketers can see if their ads are a waste of your internet space and a waste of their marketing dollars.

These are just a few of the ways that, by volunteering a little bit of anonymous information about their web usage, users contribute to a better internet- not just better for marketers and analysts, but better for internet users everywhere. Regardless of current legislation, the Web Analytics Industry must put effort into educating the public about what is being tracked, why, and how it benefits the average user. Where do you stand?