This week we have a host of stories, including Google’s Big Query data analysis, using open graph buttons, and theorizing on the next step of Google places.

Create

• We start the week with A List Apart and why you should just say no to faux bold.
• Next up, Get Elastic has 5 tips for custom Facebook open graph buttons.

Attract

• Last week Google announced the release of Google+ Hangouts on air. Now you can live broadcast your hangouts in all of their blurry glory.
• David Mihm theorizes about an upcoming merger of Google Plus and Google Places. This could be a very interesting strategy on Google’s part to distinguish themselves from other local services.

Analyze

• last month Google finally announced their Big Data analysis tool Big Query. This new analysis option allowed businesses to gain real-time insights from huge stores of data.
• Avinash takes a stab at measuring “brand strength” with web analytics.

Optimize

• Truly a post after my heart, Six Revisions has 5 reasons why Metaphors can improve your users’ experiences.
• And Bronto Blog examines ways to reduce shopping cart abandonment.

For more industry news, check out our past Monday Roundups.

The example she uses is the concept of micro-selling. Now ubiquitous in India, micro-selling is the packaging of products in tiny single servings.

The large multinationals completely missed a major opportunity because they didn’t understand the local (Indian) ecosystem. It was a small, local Indian company that intuitively understood the needs of Indians. They realized that in India, many people simply can’t afford to buy large packages of products.

And so this small Indian company hit on idea of selling products in tiny single-servings that most anyone could afford. The idea caught on like wildfire.

Apala explains how remarkable insights can come from the most innocuous conversations. But you’ll never uncover those hidden gems of insights unless you have an immersive experience in the target ecosystem.

The bottom line is that you must understand the ecosystem your customers reside in, especially in emerging markets where the ecosystems – local customs, needs and realities – differ dramatically from the West. If you don’t, you’ll miss the mark.

Caveat: The audio is pretty bad, with all kinds of background traffic and conversation. But trust me, it’s worth enduring. Besides, the background noise just makes the video that much more authentic. Enjoy!

Here’s how I would do it if I wanted a really good Google Analytics implementation specialist.

There are two schools of thought: Joe Hall at Marketing Pilgrim says “Don’t Waste Your Time Learning To Code” while Michael Jaconi explains “Why one company is making all its employees learn how to code” at VentureBeat. See my take at the end!

Anyone can pretend to be a hero

While vendors claim you can easily copy & paste of a couple of JavaScript lines on every page, anyone who has done advanced implementations knows this is false. Can anybody create a free Google Analytics account and copy the classic tracking code – after all, understanding HTML and basic Javascipt is easy, right? Or is it? Really?

Either you get it… or you don’t

We are not seeking the usual junior or occasional developer – we are seeking a real super hero who gets it; someone who fully masters the ins & outs of JavaScript and already have a certain level of Google Analytics implementation experience. The following can serve as an example for those on the technical side who wonders if they have what it takes!

Step 0: Here, we take for granted the usual HR filtering has been done and there is a good personality and cultural fit, soft skills such as listening abilities, problem solving, and communication have been validated. We are going deep on the technical side.

Step 1: A real super hero is always ready to jump straight into action. When seeking a very good implementation specialist, look for web development skills along the lines of:

• JavaScript programming;
• Knowledge of DOM (Document Object Model), jQuery or other libraries;
• Adobe Flash/Flex programming – as appropriate;

More specifically, we want to test knowledge of how Google Analytics tags work. Ask the candidate to explain what this code does:

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-9999999-1']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>

This should cover:

• Understanding of GA basic call structure:
  • What is an account and a web property (the UA)? You want someone who don’t blindly put tags on a page – but also understand how this code will impact the tool.
  • How the page is going to be tracked? This is also a good opportunity to ask about other types of Google Analytics calls like events, social, custom variables, cross domain, etc.
• Understanding what is _gaq
  • What is _gaq? This should cover JavaScript concepts such as FIFO (First-in/First-out) array where we push() Google Analytics calls;
  • Is there a way to do a single _gaq.push() instead of two? (hint: yes!)
• Understanding Google Analytics async concept:
  • What does it implies in terms of performance impact? Does it matter if the code is at the top or bottom of the page?
  • Why is there http & https in there?
  • What does the createElement, getElementsByTagName and insertBefore do here? Those are all standard DOM (Document Object Model) JavaScript calls.

Step 2: Is your pretending hero still with you or ran away screaming? The 2^nd test level is more holistic and will stump all but those who really have the right profile. Ideally, you want to give them a specific page that includes jQuery but no GA tags. Ask them a) what they would track and b) how they would do it (the actual code).

The page elements you want to cover might be:

• Page tracking: What is the GA call to do page tracking? (Covered from Step 1 above)
• Social interactions: How are social media interactions being tracked? You can put addThis, shareThis or similar on your test page.
• Cross domain & outbound links: Include a checkout link to a shopping cart hosted on another domain (should identify cross domain issues) or at least a link to a 3^rd party shopping cart like Paypal which should be tracked as an outbound link virtual page view or event.
• Internal promotions: You could also specify there’s click on an internal promo-banner you want to track (an event).
• Events and custom variables: You want to track user logins – a simple page view on the logged in page, an onclick event on the “login” button or link, something else?

Limit the time to about 30 minutes, but allow them to use the web and if you can, record the session. Alternatively, simply discuss those points and see how the candidate is able to answer.

Step 3: Other discussion points might involve the following – they are aimed at having an open discussion and evaluate the candidate ability to communicate effectively, do problem solving and ultimately, admit what they know… or don’t know:

• Even if you don’t have a fully working ecommerce demo with a “thank you” page, ask the candidate about what should be tracked from an ecommerce perspective and conversely, the challenge of tracking 3^rd party ecommerce conversions (Paypal or others).
• How does internal promo differs from tracking inbound campaigns? Is it good to use regular campaign parameters for internal promotions? (hint: no! this will screw up your campaigns data!)
• Suggest using the login username (suppose it’s an email) and storing it in a custom variable. Ideally, the candidate should have already mentioned the possibility of storing the user id in a custom variable for back-office integration. It’s a good opportunity to touch on privacy – the candidate should clearly explain why storing the email in a custom var would be bad (hint: compliancy to GA TOS, DAA code of ethic, and overall bad practice!)
• Ask something that is impossible and see how the person react. Here’s my story:
  Several years ago, during an interview I was asked how to find the missing ball from a Bingo cage. I don’t think there are many ways… retrieve balls one by one, sort them, and you get the missing one. Right? Do you see any other ways? I didn’t… until*…

All super hero stories have a moral

You don’t want a robot spitting out fancy JavaScript code from the darkest corner of the office.

Human skills trump any technical ones.

Ultimately:

• look how the candidate reacts to more difficult questions or things he/she doesn’t know;
• the candidate should ask questions and not take everything for granted – look for communication skills;
• be aware of problem solving skills – a good developer is a problem solver, someone who is creative enough to find solutions and not merely use Google to search canned answers, such as I highlighted in “Undermining our future as web analysts”.

My take: should everyone be a coder?

I get the nerve when I hear non-technical people underestimating the true skills required to do proper analytics implementations. Too often, I see sites that have been tagged by people who lacked understanding of advanced implementation techniques, unknowingly putting the organization at risk of taking disastrous decisions based on bad data.

Marketers can learn HTML and basic JavaScript relatively easily – just as developers can develop their marketing skills. However, I don’t believe you can easily master both ends of the spectrum. Knowing a little can make more harm than good – if it’s to ease communication, I’m all for it – if it is to pretend being able to make one’s job – I think it’s a recipe for disaster.

* Facing the insistence of my interviewer, it suddenly struck me: “well… I’ll ask the person who took the ball!”

Joe Stanhope from Forrester also just announced the Forrester’s Tag Management User Survey and those who participate will receive a complimentary copy of the completed research.

Tag management systems are valuable, but there’s also a lot of hype. You need to filter through hype, make an informed decision and understand the real value that a TMS can bring, along with the risks.

The value of TMS

Fundamentally, TMS are great for three things:

• Raise awareness of tagging importance
• Reinforce (or force) a process around tag management
• Easier tags maintenance (but not necessarily “easier tags”)

Be wary of the blue sky

As with any technical solution to what is essentially a governance issue, you need to exercise cautious enthusiasm for the “blue sky” factors – also known as “bs”:

• If you were not able to get your darn tags on the page in the first place, a TMS will not solve this issue. If you can’t establish the line of command to impose the presence of tags on every page (because of development roll-out schedules, governance issues, partners communication issues, resistance to change, politics and name it), the TMS will just requires you to go back to all of your interlocutors and ask them to strip down previous tags in favor of the TMS one. Good luck!
• TMS vendors claiming deployment in X hours is as much bs as web analytics vendors making this type of claim. All deployments should be planned carefully. Very basic tags integration in CMS templates is a given; but I have never seen full deployment of advanced tagging, let alone tagging of complex transactional pages, done in a couple of hours.
• TMS vendors claiming to get rid of IT is just bs. An easy and bold statement when trying to sell TMS to marketers… The reality is anything that is process driven – hooked up to your back office, thus, typically closer to your core business – requires tighter IT safeguards for quality, security and conformance. In some cases, like in finance, the TMS vendor will go under tight scrutiny by IT – and this is a good thing. After all, TMS are basically back doors into every page – technically, they allow to alter and capture elements present on a page.
• TMS vendors claiming to avoid vendor lock-down is bs. It’s even worse… where you had multiple single tag vendor lock-down you now end up with all tags going through a single vendors hands.
• TMS adds another interlocutor in an already complex environment. I have heard stories of TMS vendors being totally stumped when faced with certain types of tags. Finger pointing anyone?
• TMS adds a single point of failure. Regardless how good they might be, regardless how fast they might be, the reality is you add a new link into an already long and complex intertwined chain.
• The TMS landscape is too crowded, there is bound to be some market cleanup and consolidation. What happens if your TMS vendor goes south or is acquired and you end up having to switch everything? In many cases, TMS’s are palliating for issues that should have been resolved by the vendors long ago. It’s no surprise Adobe came up with their TagManager product, and expect other big vendors to follow.
• TCO of TMS. Carefully look at the incurred costs (hard) vs potential economies (soft). In some cases, the Total Cost of Ownership (TCO) can be outrageously high – I’ll leave it up to you to figure it out and negotiate the best price!

My take

Selecting the right TMS solution (Tagman, BrightTag, Satellite, Ensighten, Tealium, TagCommander, UberTags or the open source OpenTag solution) – and even validating if you should use one in the first place – can be relatively complex. As with digital analytics solutions, selection criteria involve more than picking the latest shiny new toy. This is where we come in.

There are two different flavors of parallel prototyping (or parallel design):

• Several designers each create one or more designs, then the entire group considers all concepts. The best ideas are cherry picked to create one or more improved designs.
• One designer creates multiple designs, then all designs are critiqued and the designer creates revised designs.

Contrasting the parallel process is the serial process: only one design concept is ever really considered. This one design is repeatedly critiqued and revised.

A study by Steven Dow et al* from Stanford in late 2010 compared the parallel and serial prototyping processes (using the one designer, multiple designs method).

In both the parallel and serial conditions, subjects created 5 prototype ads, then a final ad. They received a critique on each prototype. Subjects were given equal time to create each prototype and to review each critique. But the process varied:

• Serial Process: Subjects received critiques after creating each prototype.
• Parallel Process: Subjects created 3 prototypes, then received critiques on all 3. Next they created 2 more prototypes and received feedback again before creating a final ad design.

The following graphics explain the processes:

The Results

There were three major findings.

1. Quality of Designs

The parallel design process yielded better-performing designs (as measured both by expert critiques and click-through performance).

2. Design Diversity

The parallel process generated more diverse designs. (No surprise here: a serial process implicitly encourages refinement of a single idea.)

3. “Self-Efficacy” and Reactions to Critiques

This is the most interesting finding. Parallel participants reported an increase in task-specific self-efficacy (task-oriented confidence). Serial participants did not. Also, nearly half of serial participants reported negative reactions to the critiques of their prototypes; no parallel participants reported this.

The authors of the study speculated that developing multiple alternative designs encourages investment in a creative process rather than one particular idea. In the Parallel process, the critiques are viewed constructively, as opportunities for improvement. In contrast, the fixation engendered by serial prototyping causes designers to take critiques as catastrophic negations of their sole option. “With only one option, there is no separation between designer and design. Parallel offers people distance between ego and object; serial conflates them.”

So in terms of both design quality and employee morale, a parallel prototyping process is the clear winner.

As the authors noted, these findings could impact both how marketers should approach creative challenges, and how educators teach design.

* Parallel Prototyping Leads to Better Design Results, More Divergence, and Increased Self-Efficacy