The importance of web analytics

Let me start with an anecdote I once heard. The marketing department decided that they wanted a new feature in the home page. The IT team received the request and implemented it as per the requirements. Three months later, the business owner of this new feature requested a report on the performance of this new feature to the web analytics team. To the team’s surprise, that was the first time the web analytics team had heard of this feature. Consequently, had not issued any tracking requirements and there was nothing to report on. In other words, three months had been lost.

Read moreThe importance of web analytics

Agencies and DMP campaigns

Before I started working with Adobe Audience Manager, I had a very limited knowledge of the on-line advertising market. In the past, I had managed Google AdWords campaigns, but that was all I knew. Now that I have been working for some time with a few AAM customers, I have realised that the market for on-line campaigns is huge. There are many actors involved: agencies, trading desks, DMPs, DSPs, SSPs… I still have to learn more about this market.

Read moreAgencies and DMP campaigns

Detect iPhone 6 in AAM

Today’s post is going to be a different form the last few posts, a bit more hands-on.

One of the typical questions I get from my AAM customers is “how do I detect a user browsing with an iPhone [model]”. The only solution we have to reliably detect the device is through the User-Agent. Although this should be very simple, in theory, there is one problem: Apple does not want you to detect the iPhone model. Android devices include in the User-Agent the name of the device, or enough information to get it from there. However, Safari browsers include the device type (iPod, iPad or iPhone) and the iOS version, with no hint of the model.

Read moreDetect iPhone 6 in AAM

Enhancing the security of your DTM implementation

We are all aware of the importance of creating secure products. In a previous post, I explained how to set up a workflow for a DTM implementation. One of the consequences of using this workflow is that only a reduced number of users can cause damage to the website via DTM. This is also good from the security perspective, as it reduces the risks of a successful attack. This is probably enough for most companies.

Financial institutions and DTM

Having said that, we must also realise that it is virtually impossible to create a completely invulnerable software product and DTM is not an exception. Banks and similar companies take the security to the next level. For them, the minimum security level should be “paranoid”. For obvious reasons, this paranoid level of security also applies to DTM. If an attacker gained access to DTM, he could very easily inject malicious JavaScript code to the whole website, by just adding a page load rule.

There are many places in DTM where an attack could take place; this is what is called the attack surface:

  • Use brute force to get to the password of one of the publishers or administrators.
  • Find a vulnerability in the DTM UI and gain control of an account.
  • Find a vulnerability in Akamai (current provider for DTM) and gain control of the servers.

I am not implying that DTM is insecure; I am 100% sure that the developers take security very seriously, but we must never forget that there can always be a hidden security hole.

Self-host DTM library

The immediate solution to reduce the attack surface is to self-host the DTM library. You would just use the DTM UI to create the rules and, once the development is finished, download the DTM JavaScript library. You can then run an audit of the files and host them in your own servers, which you have already hardened. With this approach, all three security concerns raised in the previous paragraph are gone. Even if an attacker gained access to the DTM, he could not modify the DTM library in your production servers.

In order to do this, you first need to enable the “Library download” option, under the “Embed” tab.

DTM library download enabled

After configuring the options, you get a URL to download both the staging and production libraries:librarydownload-2

Remember to update the links to the library in the HTML, as specified in the “Header code” section:

librarydownload-3

DTM library workflow

The previous solution works, but it adds a level of complexity for the DTM users. When debugging unpublished rules, the DTM Switch is completely useless, as it only works if the library is hosted in Akamai. You need to use tools like Charles, which make the whole process more complicated: you might need a license, you will need to download the library with every rule change, you need to learn how to manually replace the live DTM files with your local version… One problem has been solved, but a new one has been created. In particular, non-technical people will find quite challenging this solution.

My proposal in this case is to use a hybrid solution:

  • Use Akamai for the development environment
  • Use self-hosting for the test and production environments

and a create new workflow:

  1. The report suites in DTM should always point to development and/or UAT values.
  2. Your friendly marketer should have access to a development server with a working version of the website, where DTM is loaded from Akamai URLs, as with the typical DTM deployment. In this environment, she can easily create and test new rules using the DTM Switch. She should only have user permissions in DTM. Any successful attack on DTM will be confined to the development environment.
  3. Once the rules have been finished, a tester should verify the correctness of them. If everything is correct, the tester should approve and publish the rules. This is different from the workflow I suggested in a previous post: now, the tester has both approve and publish privileges.
  4. An automated script should download regularly the production DTM library and deploy the JavaScript files in the SIT/UAT/staging environments.
  5. Security audits should regularly be made to these JavaScript files.
  6. When pushing the whole development environment to SIT/UAT/staging, another script or process should automatically modify the DTM links in the HTML, to point to the correct server (not Akamai). These links are those in the “Library Download” tab.
  7. Website testers should only see the approved and published rules and report any errors.
  8. In pre-production, the report suite ID of the DTM library should automatically be replaced with the production RSID.
  9. The production environment should be exactly the same as pre-production.

It is a complicated solution, but it combines both the easiness of the DTM Switch for development and the security of self-hosting.

On final note. You will have noticed that the SIT/UAT/staging environment will have a slightly different version of the DTM library, than pre-production and production, as the RSID will be different. I would also expect that server names will be different. In this case, one solution is to replace the URLs in DTM with placeholders:

librarydownload-4

Your scripts I mention should also do a find and replace in the JavaScript files, looking for these placeholders and replacing them with the correct URL.

DTM, products and W3C data layer

Before getting into the details of the post… Happy New Year to all of you! I hope that 2016 is full of DMPs, DTMs and Analytics 🙂

Now, going back to today’s topic, I want to talk about how to create the products string in DTM using the W3C data layer. One of the reasons why we prefer a tag management solution (TMS) over hard-coded snippets is to write less code. All modern TMSs include features to set analytics variables using a point and click interface, usually through Web. In the case of DTM, you can create a data element that reads a data layer variable; you can then assign it to an eVar or a prop, without writing a single line of code.

However, when it comes to the products string, things are not that easy. There is no simple way of creating a one-size-fits-all solution for this variable. Let’s have a quick reminder of this variable’s structure:

which can be repeated as many times as needed, once for each product, using the comma as separator. Each element in this structure has its own rules:

  • Category. It is rarely used, as there was a limitation in SiteCatalyst v14 that only allowed one category per product. This limitation was lifted with v15, but very few implementations use it anyway.
  • Product. This is the only mandatory element.
  • Quantity. Only on the order confirmation page.
  • Price. Total price of all units combined for that product; only on the order confirmation page.
  • Product-specific events. Optional.
  • Merchandising eVars. Optional and, usually, only on product view or add to basket.

Data Elements for products

As it can be seen, there are many potential combinations of these elements. As a consequence, my recommendation is to create one data element (custom script) in DTM for each of the cases. For example:

  • Product listing page (PLP)
  • Product description page (PDP)
  • Cart page
  • Add to basket
  • Remove from basket
  • Order confirmation page

products-dtm

As an example, on the order confirmation page, you could use code similar to the following:

In this example, if a product is a gift, event48 should also be set.

Remember to use the correct data layer object for each case:

  • digitalData.product: PDPs and PLPs
  • digitalData.cart: add to basket event, cart and checkout pages
  • digitalData.transaction: order confirmation page

I have already described some details about digitalData.product and digitalData.cart in my post The W3C data layer – part II.

Products in rules

As you know, the recommended approach to set Adobe Analytics variables using data elements and is to use directly the UI:

dtm-vars

However, the products string and the purchaseID variable cannot be set through the UI. The only option is to set them in code, using something similar to:

Please note that the events string must also be updated depending on the product-specific events. Following the previous example, event48 needs to be set only if it is set in the products string. In rules where the Adobe Analytics call is s.tl() , DTM will detect that s.products  has been set and will add it to s.linkTrackVars , but not the events in it. Thus, the variable s.linkTrackEvents  must also be updated. For example:

Be careful if you use “eventX” without the equals sign (=) in the call to indexOf() , as there is the small risk of setting the wrong event. For example, s.products.indexOf("event12") will detect event12, but also event120event129.

DMP Low-Hanging Fruits

In my experience as an Adobe Audience Manager consultant, I have noticed that many clients need a lot of hand-holding at the beginning when working with this DMP. Coming from the Web analytics world, this was a bit of a surprise to me at the beginning. I remember when I started an Adobe Analytics project I worked on 6 months ago, one of the client teams had a spreadsheet with 138 requirements… and that was only one of the teams involved. They knew exactly what they needed from the tool, which made my life easier. However, this is rarely the case in an AAM project.

In order to get some quick wins, we recommend to start with the low-hanging fruits. For your first few campaigns, do not try to create very complex rules for segments. Instead, think about easy rules that only require online behaviour. Here are a few of them:

  • Exclude customers from prospecting campaigns. This is probably the easiest case and the one that makes most sense: stop showing prospecting ads to users that are already customers; you are 99% sure they are not going to convert. This is as simple as creating a segment with customers and send it to the DSPs. Then, using the exclusion capabilities of the DSPs, exclude the visitors in that segments from the prospecting campaign. One of my customers had a drop of about 20% in the cost per acquisition just using this technique. If you use AAM with Adobe Analytics, here you have a few examples of the traits you can use to detect that a visitor is a customer:
    • The log-in event has been fired: (c_events contains “eventX”)
    • If you are capturing the CRM ID in an eVar or prop, then something as simple as (c_evarX/c_propY matchesregex “.+”) should do the trick
    • Any page of the private section (e.g. c_pagename == “my:private:area”)
    • Depending on what you sell, it can be as simple as users who have purchased something: (c_events contains “purchase”)
  • Include only local visitors or exclude non-local visitors. Very similar to the previous case, if you have a business that only sells locally, you do not want to waste any money on banners shown to visitors that come form regions where you are not going to delivery your goods. In AAM, this is very easy with geotargeting with platform-level keys.
  • Retargeting abandoned baskets. For all of those products that provide you with a high margin, you can create segments with users who have abandoned the basket with those products in it. You then create very specific retargeting campaigns using these segments. The segments will formed of two traits: “Add to basket – <product id>” AND NOT “Purchase – <product id>”
    • Add to basket: (c_events contains “scAdd” AND c_products contains <product id>)
    • Purchase: (c_events contains “purchase” AND c_products contains <product id>)
  • Up-sell or cross-sell. Target customers that have recently purchased certain products, customers who your experience (or your Web analytics data) shows that they are very likely to convert again. This is as simple as the previous example: (c_events contains “purchase” AND c_products contains <product id>)
  • Frequency capping. If a user has seen a campaign more than X number of times, stop showing the campaign to him. You need to decide which is the optimal X, but we all know that after a certain amount of times, if the user has not clicked on a banner, it is very unlikely that he will do it in the future. In AAM, you would use the frequency and recency capability of the segment builder.

What do you think about these initial segments? Any other segments you would recommend as low-hanging fruits?

 

When to use and when NOT to use DTM

A while ago, a customer requested a call with me to discuss one issue. Usually, I get more technical questions, but this time, he wanted to have my input regarding something completely different. The developers had realised that they forgot to include a JavaScript library in the website and they could not add it immediately, due to code freeze. They thought of an alternative solution: load it through DTM. My customer, from the marketing department, was not sure whether this was possible or acceptable and, therefore, wanted to know my point of view.

I must admit that, initially, I was a bit perplexed and did not know exactly what to reply. This was the first time I received this question and I had never thought about it. However, I quickly came with a proper answer and this is what I suggested. It must be noted that this is my personal perspective, not Adobe’s.

In order to reply to this question, you must first think about governance. Who manages DTM? Who owns DTM in the company? What is the purpose of using DTM? I think that DTM is a marketing tool, managed by the marketing department, used to deploy marketing tags in a website. So, if the new piece of code that needs to be added to DTM is requested by the marketing department, then it will probably make sense to use DTM; on the other hand, if it is the IT department requesting the addition, I would recommend against using DTM for it.

Technically, it is possible to deliver any JavaScript (and even HTML) through DTM. However, the fact that it is possible does not mean that it should be done. Think about the following questions when adding a piece of JavaScript that was not requested by the marketing department: who owns that piece of code? who updates it? who fixes it if stops working? who is to blame if it is inadvertently removed? what happens if DTM is removed? The marketing team will not want to take any responsibility of code they do not even understand.

So, to summarise, from my point of view, here you have some cases that are suitable for DTM and cases that are not:

  • In DTM:
    • Web Analytics tags (like Adobe Analytics)
    • Optimisation code (for Adobe Target, for example)
    • DMP tags (AAM also has a module in DTM)
    • Third party re-marketing tags
    • On-site surveys
  • Not recommended in DTM:
    • Generic JavaScript libraries (for example: jQuery)
    • Website functionalities (chats, UI effects)
    • Code that needs to be executed in a very specific location of the page (i.e. not at the top or the bottom)
    • CMS libraries

Can you think of any other case that would fit in one or the other case? If so, please, leave a comment!