Sunday, 1 September 2013

Know your Traffic

Do you know where your footfall comes from?

I have seen too many advertising fall victim of this simple technique that I can no longer stay silent.  And it shocks me that marketers are not doing more to keep this from happening.

I was watching TV and noticed an ad for a major company promoting a great offer.  I typed the site in and realized to my horror that they were not tracking where I came from.  Nothing.  I then kept an eye out for this same offer around town.  I found it on the trains, newspaper and magazines.  But just like the TV ad, they were not tracking where they were coming from.  All four directed people to the homepage.

But why do this?  They are spending considerable funding to get new customers, but they do not know which is working best.  And why would they not track?  Wouldn't they want to know what their return on investment?  Take the learnings for future campaigns?

If I could have my way, I would of had 4 different campaign codes for each of the four different advertisement methods and determine which I got the most for my money.  Maybe even tested it for another campaign and learn which is best.  Then, for the TV ad, I would know which times are best to air my commercial - getting even more for my money.

But is this just too much to ask?  Or is my shock in the lack of tracking shared by others?  I would be curious on what you would do if requested to lead a marketing campaign?  Would you track where they are coming from or promote the homepage?

* Image came from:

Saturday, 31 August 2013

If I could do it again: Setting Expectations

While thinking on “what would I have done differently”, I remember when a key stakeholder told me that he believed the analytical tags are broken.  I was really shocked because this particular person never questioned the data before.  This got my full attention immediately.

I asked ‘why do you believe the tagging is broken’.  The response that I got back was the one phrase that I was not prepared to hear.  And I know that this is a common phrase.  I know that nearly every Web Analyst has heard this before.  But when a key stakeholder says this, one that has gotten as involved in the implementation of the tags, I did not prepare myself for the response.

How Many times have you heard this?

“I believe the tags are broken because the results did not match what we believed should of happen”.  WOW!  I cannot believe people are questioning the data.  I mentioned that I would double check the tags, but I was fairly confident that these tags are set up correctly.

I sat with the developer responsible for tagging on this particular application and we confirmed that it was working correctly.  We even double checked with the logs and the logs even proved it was correct.  That is when I said my most favourite phrase.

A saying every Analyst has wanted to said, but never could.
 “Digital Analytics is used to tell you what actually what happens.  It is not used to prove what you believe should happen”.  After I said this and thought about it, that is when I came up with the company name “Webbing Your Way”.  When a company creates a site, they have plans for how each of the pages work, the paths customers will follow, etc.  But what they fail to remember is that their customers do not know this.  Have you ever seen a site have a page that says “this is how you use our site”?  No!  They believe customers will naturally go down these paths.

That is why Webbing Your Way!  The customers decide how the site will be used.  They will determine the paths they go down.  They will use your site the way they want.  An offer pushed live did not perform as well as you thought?  Well, was this offer as good as the Customer thought it should be?

So if I could have it to do all over again, it would be to set expectations early with the stakeholders.  For so many years, businesses have made decisions that were based on their gut feeling.  Now that they can prove if their gut is right, they are in conflict.  Their gut says it is correct, but the data says otherwise.  They were taught to go with their gut, but we are telling them to go with the data.  That is why every company I go to now; I ensure that I tell everyone that the data tells you what actually happens.  Nothing more.  Nothing less.

While looking for pictures, I found this qoute which sums up this topic nice.  Following your gut is great, but it works even better when complimented with analysis.

This is an excellent quote for all analysts / marketer

*pictures come from:

Sunday, 25 August 2013

If I could do it again: Report Suite ID Naming Convention

It is now coming up to 4 years since I have started in the Digital Analytics industry.  And for more than 3 years, I have spent with a single company in a unique position: assisting with the migration from HitBox to Omniture (now Adobe Analytics).  Now I have thought back to this time with a simple thought: “If I was running the show and had a chance to redo everything – what would I do?”.  I will have a small series covering this topic. 

But while I was thinking about this, I had one that came straight to the top of the list.  This is one thing I wish we had done as it would have saved a lot of time, energy and headaches now days.  This of course is consistent Report Suite ID naming. 

Oddly enough, this is something that Omniture never covers and I hope they would listen to this post and recommend future customers to consider this and hopefully, follow my suggestion (and listen to my mistakes).

Current Issue:  I wanted to create a Report Suite Group for all accounts that are used on our live environment (thus, the data the analysts use to report back to the business).  The problem I have found – there is no format.  Some Report Suite ID’s have prod, dev, stag – but not all.  Some indicate which environment they belong to in the friendly name, but not all.  So, there is no way of indicating in the very short Advanced Filter. 

Now the company I work for has 500+ report suites.  I did the only thing that I could do: go one by one and guess which ones go where.  Later, I will do a mass edit and change the names for the report suites that are no longer being used. 

But what could I have done differently that would have saved a lot of time?  Not only consistent naming, but a naming format.  When Adobe Lists the report suites in Admin, it is done alphabetically based on the report suite ID.  What if we had a naming convention that would group like report suites together, and can easily filter for what you want?  Here is what I had in mind:

          1)      Company ID.  Adobe uses this to ensure they do not have multiple Report Suite ID names across their numerous clients.  This is something you cannot edit after initial setup
          2)      Environment: This indicates if the report suite is for Production (live), Development, or Staging.
          3)      Type: which type of report suite is this for?  Web, App, Mobile, etc. 
          4)      Optional * device type.  If this is for Apps, is it for Android, iOS, Windows….
          5)      Unique Name – the unique name or Site name for the report suite.

An example for WebbingYourWay blog would be:
                a)      Web production / blog: wywpwblog.
              1.       Company ID: wyw
              2.       Environment: p – this indicates production.
              3.       Type: w – this indicates web
              4.       No optional
              5.       Unique name – Blog
         b)      Web Development / Blog: wywdwblog
             1.       Company ID: wyw
             2.       Environment: d – this indicates development.
             3.       Type: w – this indicates web
             4.       No optional
             5.       Unique name – Blog

        c)       App – iOS Staging / Executive Dashboard: wywdaiexecdash
            1.       Company ID: wyw
            2.       Environment: s – this indicates staging.
            3.       Type: a – this indicates it is a mobile app
            4.       Device type: I – this indicates the mobile app is for iOS
            5.       Unique name: execdash – this indicates this is for the executive dashboard.

By doing this, all your environments are grouped together, making it easy for you to create a group for your production.  You have a simple way to get to your mobile report suites, all of your iOS report suites, etc.   Your Admin -> report suite section is simple to understand. 

If I could roll back time, this is the first thing I would insist we would do.  Now, if only I could rename these suites now, I would be golden.

Sunday, 14 July 2013

Adobe Marketing Cloud Release notes

For those that went to the EMEA Adobe Summit 2013, you saw what the future of Adobe Analytics.  This includes a new look, feel and renaming of products.  And the future is arriving this week.  To be exact, the future arrives on the 18th of July. 

The first change users will see is an updated interface: from the layout to reports down to how the sign-in page.  The new sign-in page looks amazing.  The only possible criticism I had during the Summit, which I still hold today.  They have added code that will change the background of the page to match what your company does.  So, when you type in your company name, the background will change automatically. 

The possible issue I have with this is one word: WHY?  If I was to ask each of you “can you name 10 things you wish were different about SiteCatalyst”, 100% of the response would not come back saying the sign-in page doesn’t look like it belongs to my company.  I feel that if they spent more than ½ day to create this, the time should have been spent working on the idea exchange ideas.

The next change, which everyone I have told asked “what were they thinking”, was renaming their products.  Nearly every tool under the Marketing Cloud has a new name.  The three which received the largest change:

SiteCatalyst -> Marketing Reports and Analytics
Insight -> Data Workbench
Discover -> Ad Hoc Analysis

SiteCatalyst was a great name!  Let’s dissect the name.  Site and Catalyst.  The definition of a catalyst is a person or thing that precipitates an event or change.  With this in mine, the tool literally means “ a thing that precipitates a change to a site.  What a great name!  Marketing Reports and Analytics – this is very generic, describes what it is used for, and is just too long. 

Before: Have you logged into SiteCatalyst and saw the impact the new marketing campaign had?
Now: Have you logged into Marketing Reports and Analytics and saw the impact the new marketing campaign had?

Next, while Insight was a generic name for a tool, it described exactly what he was meant to do.  Now, Data Workbench…. I cannot really criticise the move.  Insight had a great sound to it, but it was too generic.  Using any of the tools should drive insight, so having a tool called Insight was misleading.  I guess the question I have was “what other names were on the table”!  What did you turn down where you ended up with Data Workbench?

This means, within three years, they have had two name changes.  First, Omniture to Adobe Analytics (this was needed and approved).  Now, they are changing their fundamental analytical tools.  Only time would tell if this would have an impact.  But I feel they should take a tip from Coca-Cola: while the look and feel of Coca-Cola has changed, the name has stayed the same.  The real power is the name.  In a couple of years, there will be an issue at work where veterans will still refer to the tool as “SiteCatalyst” while the new generation will call it by the new “Marketing Reports and Analytics”.  Less than a year ago, this book came out:

Does anyone else see where the issue is?  And there are two other books that directly references SiteCatalyst in the title.  One book is not even released yet!  This book (Adobe SiteCatalyst 15 Quick Reference Guide) comes out 25th of July.  The tool gets renamed on the 18th of July.  The book is already outdated before it is released.

Ok, no more about the cosmetics.  The public facing release notes about the changes were 14 pages long.  There were 9 technical changes and one announcement. 

SiteCatalyst 13.5 is coming to an end.  Come October 2013, this will no longer be accessible.  The one feature, which I found out was available in 13.5 but not in the future releases, was notes on alerts.  Why did they remove this feature in future updates?

Technical Changes:
Historical trend lines will be displayed for all custom date ranges, even if you select the period (even ranges) and when you use the day of the week option.  This is one feature that was badly needed.  I never knew what the logic was for showing the historical trend lines were.  No matter what I tried to do to get it to show back up, it seemed once it was gone, it stays gone.  Now, it looks it will finally show up easier than previously.

Advanced Search:  When using the filter, the “|” used to be an unavailable character – completely ignores this character.  Now,, we can finally search on it.  And while we are on search, Report Builder will now allow the same advanced filtering enhancements that Marketing Reports and Analytics (SiteCatalyst) enjoys.  Now you are able to use the Equals, Starts With, Ends With and regex.

Mobile App and Social Metrics: These metrics are now available within Ad Hoc Analysis (Discover), Report Builder and Web Services API.  Now that these are finally available in Discover, I really hope we can actually segment on these Metrics.  The one segment I would love to create is “Visitors that experience a Crash”, and see if there is any patterns.  The only way this is possible is if we use processing rules to copy this event into a custom event…. Kinda beats the purpose of these events though.

Data Warehouse:  There were two key updates that I am really glad they finally enabled.  eVar Participation Metrics are now available to be used and reporting back hourly granularity even if you are reporting on more than 14 days.  While the hourly granularity would not be beneficial if you are using any dimensions against it, it is perfectly valid to pull back a metric by hour, wanting to see a trend for the past 6 months.     

Classification Rule Builder: this was only updating the previous month – a fix was put in place to ensure it is updating the last 6 months as it was supposed to. 

While these are not all the changes that are being released, these were the key features I felt were the most important.  If you would like to see the full press release on these changes, please check Adobe’s microsite.