I found an interesting question on the Web Analytics Association (WAA) Group discussion board at LinkedIn. Rachel Lewis asks, “How can you modify your site optimization plans to deal with the emergence of plug-ins like Kikin?” The discussion can go in several directions from strategy to planning to techniques, but what peeked my interest was how does Kikin, Cooliris and other plug-ins change what we see and measure on our web sites. I have wondered the same thing as I zip through search result links with Cool Previews from Cooliris, which pops up the web page with a mouse over. Kikin takes the tool bar to a new level by actually inserting not only content but Web 2.0 application into the center of search result pages and providing summaries and links to one’s favorite social media such as Facebook and Twitter and even potential competitors such as Bing, iTunes, Yelp, and Amazon. What does that do to our perception of web not to say also our understanding of marketing channels?

The question seemed to be important enough to dust off my old proxy server code that captures the data stream between the browser client and the site servers to check out what is happening.

Whenever a new technology or technique is added to the mix, before all else, one has to ask: “Do I have an ability to determine what is really happening?” The question cuts to the core of Web Analytics, since visitor behavior is never observed directly, only the effects of the behavior. Its like tracking where a scout can interpret direction and sometimes intent from tracks and droppings. Like the tracker, the web analysis has to construct the behavior from the collected evidence. So the purpose of the proxy server is to collect the evidence and see if the new technology leaves a trail to follow.

First let us look at Kikin not only because it pushes the boundary of tool bars onto the actual pages being served but nicely illustrates how custom plug-ins can alter how we view our marketing channels. I would speculate that any given add-on has a small effect on any given site, but that the accumulation of many different ways that customers use their browsers and social networks to come your site can be of intense interest. It would be good to be able to collect the data to put this speculation to the test.

To briefly summarize, Kikin is a plug-in to a browser requiring user approval such that once installed becomes an integrated component of the browser. It typically presents a toolbar at the top of the web page, providing drop downs from popular social network sites and Kikin “partners” that might be relevant to content of the page just loaded. It does very well to keep the person engaged on the page without leaving the page. If relevant, one can access iTune songs and sample on the same page that discusses the song or artist. Likewise one can view YouTube clips, read Wiki articles, scroll Flickr photos without every leaving the page. That is cool!

As an integral component of the browser, it has a much larger sandbox to play in than scripts inserted into the web page on the client by a server. In fact, it can insert its own scripts and become part of the very page being loaded. For search result pages from any of the major search providers, Kikin inserts content at the top of the web page, just below any sponsored ads that everyone has paid dearly for but above the organic and natural search results, which are pushed below the fold. If the search results page does not serve ads for the particular keyword, Kikin provides sponsored links from their partners along the side bar. Isn’t that considerate?

Ignoring the issues of trust, security, ethics and business models, what are the ramifications of this on traffic to ones site? The net effect is that referrer / landing page pairs that web analytics depends upon to determine where and how visitors come to the site are scrambled from what you would normally expect. For example, one could have their MSN ad come from a Google search result page for a keyword that they did not directly purchase, or a natural search result from Bing or social media campaign come from an unknown referral site. Hopefully Kikin’s context engine will continue to improve so that referrals have contextual relevance but its not guaranteed – at least at the moment. So it is possible that the clicks will come from sites that seem to have no relationship to your site or content.

The reason for this illustrates how reality is constructed from the tracking evidence gathered from web analytic data. Because the toolbar and inserts are part of the web page, any clicks within these components will show in the server logs as clicks coming from the parent page URL. An important axiom of Web Analytics (yes there are 5 of them) is that “data that appears the same will be interpreted the same”. Think about it! Unless the behavior we want to track leaves some form of evidence, it cannot be observed and will be miss(ed)-interpreted as something else. In this case, the possibility of a MSN Ad click from a Google domain. I suppose the absurdity of the pairing is evidence. Unfortunately this approach cannot cover all situations, such as the possibility of Bing clicks on the Yahoo! domain.

Anyone can observe this from the info available from the browser. For example, FireFox provides a pretty complete break down of the response header in page info. The reason for breaking out the proxy was to see if there was any evidence left from the Kikin component and how the component communicated back to its mother ship. In particular I am looking for modifications to the User-Agent field or the addition of a non-standard field in the HTTP request header. There are none.

The reasons that the User-Agent field would be appropriate is that typically proxy servers will add a Via phrase at the end of the browser value to indicate the intermediary to which the server replies with more specific caching instructions. A similar situation arises here. The request is not coming from the browser we have all learned to love and know, but a modified browser – a personalized browser – pimped out browser. How many ways can it be pimped out? I would imagine as many ways as there are users. So some form of pimping instructions would be useful.

The web analytic instrumentation or server logs can pull down all of the components and plug-ins installed on the client (perhaps a good defensive start), but one still would not know when the component was specifically responsible for the referral. Besides IT would be clamoring to turn the dang field off since it would filling up log files at an alarming rate.

Since the component has in effect invalidated the Referer (sic) field, a more appropriate approach would be a modifier field in the request header that indicates how the Referer field should be interpreted by the server or down stream web analysis. For example, call it Referer-Modifier with the value being the plug-in/component user-agent name that orginated the request. This is an approach that would require each browser to modify its API for plug-ins to require notification for events originating from the component that effects the referrer or content serving. But just the same, this would allow one to segment by plug-in, which could be very useful.

For example, Cooliris provides a service to its customers through Cool Preview by popping up “lite-weight” windows to view content without leaving the current page. So these can be properly interpreted as valid referrals if not clicks. However as one is scanning over the links (to take a peek underneath so to speak) the serving site is receiving the much dreaded “Bounce” back or one click session. I would argue that the site would not even get the click at all if the user had to click through to the page, so it doesn’t seem fair to think of these as bounces but more as opportunities. If there was somehow a way of segmenting these bounces from click bounces, one would have better understanding of what is really occurring. Further if this was indicated in the request header, the serving site could adjust the content more appropriately. This is likely what Cooliris is trying to avoid.

Cool Preview is very conscientious in rendering and running the page exactly as it would in a new tab within the browser. It even stacks requests so that if the pop up is pinned or converted to a browser tab, one can navigate through the stack just as they were “scanned” in from the original page. That is the cool part. From the serving web sites perspective, the scan in is recorded as a click and if the top page scanned is converted over to a browser tab, the page is re-rendered but not necessarily reloaded such that the web server gets the notification. If the page is “tagged”, the instrumentation should be able to observe and report both events and including the Cool Preview frame. In this case, there is a defense strategy to account for this particular plug-in. But still – as a general rule – it would be nice to be notified when the referrer field has been modified from its standard interpretation.

With respect to Kikin, there are no such defenses since the action is taken before the user comes to your site. For the user, it does enhance the experience on the site, allowing the user to explore iTune and YouTube content, tweet or face without leaving the page. Since on most searches, Wikipedia is typically one of the top results, Kikin’s app allows the user full access to the relevant Wiki results so that at least those results can be quickly scanned within the search page.

On the back-end there are appropriate communications to the mother ship that allows Kikin to provide appropriate data to its partners (so that Bing, for example, can know when its content is being served from Kikin). Unless you plan to be a Kikin partner, the effects will vary widely depending upon your site. In most cases it will have little effect unless you are initiating social media campaigns through Facebook and Twitter.

You can still perform your SEM planning and tracking using (and trusting) your tracking parameters for your campaigns. You may want to look at the domains from where these ads are served and make appropriate adjustments with placement with the Kikin partners such as MSN. For organic search, SEO plan should look at both placement within Bing and whether these will be served in Kikin search result pages, which are limited to the top 10 results. In these keyword markets, you may find the Kikin effect kick in. If you want the kick in, you will need to coordinate your SEO and social network marketing since Kikin tool bar at least for now will popup within the nexus of search and social media sites such as Facebook. Kikin after all is a social medium mashup, so if you plan to participate, Kikin or its ilk will have to be considered.

However to understand how Kikin or any other personalization fly-by-your-pants wild-n-woolly Web 3.0 mash-up will effect your business, you will need data. You will need tracks that indicate where and how traffic is coming to your site if you are to have any chance of understanding what is really happening. Tracks and droppings is how Web Analytics sees reality. I will leave it for discussion what the analogs for tracks and droppings are in web analytics.

But I gotta say – it would be nice if the plug-ins left some tracks or droppings, which ever ended up applying.