Burning Tag

CASE STUDIES: TOPSPIN PURCHASE FLOW – INTRODUCTION

Topspin’s purchase flow had served its purpose for the 18 months of its life and worked as a successful early-life product. Topspin needed to prepare a broader-based, more easily integrated purchase flow. This case study will examine the early-stage technical innovations that Burning Tag helped to realize product goals, as well as later product improvements where Burning Tag provided strategic guidance to allow increased impressions and conversion.

 

 

THE COMPETITIVE LANDSCAPE: YOUR PLACE OR MINE?

At its core, Topspin’s purchase flow is an e-commerce tool that does not require bolt-on additions to your chosen CMS. All products are maintained in Topspin’s system and functionally, it is wholly separate from whatever system your website is based on. As a result, the Topspin integration is not very different from similarly functioning “shopping carts” and e-commerce solutions (though the scope of Topspin vastly exceeds a “shopping cart” function).

 

The major point of differentiation for the first major revision was in the method of integration. Virtually all competitors at the time (and a majority to this day) required you to link to their hosted storefront – e.g. burningtag.myshoppingcart.com – where you could perform some rudimentary customization. Usually this was limited to headers, a few colors, and a handful of pre-designed store page layouts. Topspin decided the best point of integration was on the artist’s site itself, so that when a user clicked to a “store” link they would not be redirected to third-party site. Furthermore, this approach would allow the artist to transact on ANY page in their site, not just a walled-off store section.

 

The logical end of this was to determine the smallest possible footprint an integration could have on an artist’s site. The integration would be carried by a single embed code, which consisted of two parts:

  • A link to a Javascript file hosted by Topspin – This allowed Topspin to roll updates as necessary to the purchase flow at a small cost of retaining some backwards compatibility. This file would perform all the necessary actions upon loading into the page: inject its own CSS file, create the elements on the page necessary to complete the lightbox effect, and when called, inject the purchase flow itself into the DOM and position it correctly.
  • An anchor tag with a Javascript action to load the purchase flow in the onclick attribute – An anchor tag was seen as the smallest functional piece that we could put in the page, with the most opportunity to be useful. The anchor tag was generally compatible cross-browser for responding to onclick actions, and allowed styling via CSS or could be used to wrap images representing stylized buttons. More advanced users could look at the code that was executed in the onclick event and integrate them into their own local function, or incorporate into their own Flash files.

 

The Javascript proved to be the most important part of the integration then. Knowing that the buy buttons would likely continue to evolve over time and that functionality in general would improve, we sought to isolate the inner function of the javascript from the commands used to call it. One of the most important ways this was done was via a JSON object used to initialize. Instead of launching via a command like:

TSPurchase.Load(123, 57975, 8088182);

the parameterized object allowed the hand-in of anything that might possibly be needed in the future (Google Analytics tracking codes, any form of future parameter, etc):

TSPurchase.Load({aId:123, bId:57975, cId:8088182});

 

As a result, Topspin retained the flexibility to deprecate parameters silently or map them appropriately if the interface changed. This also fixed the problem seen in other similar pieces of code which had ever-growing lists of variables passed in via the function call – frequently with many values nulled.

 

The next major challenge was making the page ecosystem receptive to Topspin’s purchase flow. Briefly, it consisted of the actions before – injecting CSS, injecting elements into the DOM, and adding Flash elements to the page. The last piece was the purchase flow itself, capable of cross-domain communication with ease. The cost of using Flash at this point was minimal – we merely needed to use a minimized form of SWFObject to inject directly into the page. Other Flash elements needed to be hidden to avoid competing for topmost z-index, but they were restored after the purchase flow was dismissed.

 

With these elements in place, we launched and proceeded with the usual debugging tasks: improving the Javascript’s ability to correctly draw the lightbox when confronted with unexpected CSS layouts, tweaking the position and behavior of the lightbox when launched (it used to follow the browser window as it scrolled, so it was “always present” – seemingly desirable until the users with smaller screens started using it), etc.

 

FIRST EVALUATION: GROUNDBREAKING; COULD BE BETTER.

When this launched, we were met with some disbelief that the integration was as straightforward as it was. For some users with more advanced needs (complex merch offerings that the Topspin platform didn’t support well at the time), there was still a fair amount of heavy lifting to complete on the integration. However, if your needs were straightforward, the integration was quite easy. Grab the code, drop it in your page, and go.

 

The first problems we started seeing were not entirely unexpected. The CSS injection was meant to be as non-invasive as possible, and at as low of a specificity as possible. However, within weeks we found that it wasn’t too difficult for users to unintentionally overwrite styling of the purchase flow. General rules in local stylesheets (declaring all div elements as floats, for instance) wreaked havoc on the window by causing it to disappear or clip the purchase flow. Other times, margins would be set on object, anchor or div tags that would alter the presentation to be less than ideal.

 

The purchase flow integration worked in environments it was never expected to work without formal relationships (notably, the first attempt to put a purchase button into Ning worked without a hitch). It also generally played nice on WordPress blogs, though there were points of fragility. In any case where <script> tags were routinely stripped, the purchase flow would be entirely non-operative – this ruled out WordPress.com hosted blogs and MySpace, among others.

 

In addition to the technical aspects, there were two drivers for the next major revision to the purchase flow. Twitter and Facebook were at this point the fast-growing, important touch points that Topspin didn’t have any functioning purchase solution for. Solving these would mean needing to work around the limitations of both of those services (and of others) – a localized solution for Facebook; a fail-safe method to work when <script> were stripped; and perhaps something that would kick things off in Twitter.

 

The other environment that had to be contended with was Apple’s iOS environment. Its explosive growth, especially on the strength of the iPad, posed a problem for the flash-only devices. In general, a more considered approach to mobile devices was necessary.

 

 

SECOND INTERATION: INTERNET SCALE MEANS IT WORKS EVERYWHERE.

It became clear that by dispensing entirely with the notion of any sort of Topspin-hosted page, there were too many opportunities for purchasers to slip through the cracks. The first task for all of these flows was to create a home page for each offer. These home pages were automatically generated and were provided virtually unstyled, essentially to minimize objections to the page aesthetics.

 

The next step was to alter the format of the anchor tags. Instead of containing a void function in the onclick, the anchor tag would contain a regularly-formatted location in the href attribute. Thus,

<a href="javascript:void(0);" onclick="TSPurchase.Load({aId:123, bId:57975, cId:8088182});">Buy Now</a>

became

<a href="http://app.topspin.net/store/burningtag/123/largetshirt?aId=123&cId=8088182&wId=12745">Buy Now</a>

 

The Javascript that would initialize the page now would perform an additional step: look at all the links, and any link with an href pointing to app.topspin.net/store would be rewritten to resemble the old format. If the script did not run or was not present, the user would simply be linked to a static page containing the offer. The page where the user ended up would always have everything necessary to initiate and complete a transaction.

 

By using URL shortening and analytics platforms like awe.sm or bit.ly, these lengthy URLs could be shortened to simple URLs like

bit.ly/afYs3L

 

Thus, you could tweet a link or include it in an email – and that link would take you to the static page which also opened the purchase flow. We also found that these links could be IM’d and work as expected. Thus, any possible form of communication on the internet which could transmit a URL – the web, email, instant messenger connections, etc, could be the first step to kick off a purchase via Topspin. This made purchasing function at internet scale.

 

 

The next improvement was to change the Flash purchase flow to HTML. This allowed the purchase flow to show up on all mobile platforms, most notably iOS. However, by placing HTML directly in the page, the exposure to errant CSS was increased. In a pure HTML solution, there would remain some uncertainty about cross-site communication – especially at that point, when several browser releases were moving towards beta.

 

To minimize these concerns, the purchase flow would be wrapped in an iframe, successfully insulating the purchase flow from errant CSS. What little HTML that remained as an injected element was more directly targeted via Topspin’s injected CSS, which reduced problems of local stylesheets overwriting Topspin stylesheets.

 

At this point, the purchase flow could be directly accessed – which was what was used in the case of many mobile browsers. Instead of showing a lightboxed overlay, the browser would push through directly to the purchase flow page (in essence, viewing the contents of the iframe directly). The mobile use case was solved cleanly.

 

The remaining piece was to allow purchases on Facebook. Unfortunately, there was no multi-purpose solution available here – Facebook remains a protected experience. There was not a short, highly leveraged path to solution. The only way to solve this was to build a full store application for Facebook. The store application would draw offers against an open offers API provided by Topspin, and display its purchase flow via the UI conventions of Facebook. The store has since seen revisions, but capturing sales in Facebook ultimately required a much more involved build-out.

 

 

CONCLUSION

As with all commerce tools, work is never done and there will be ongoing efforts to improve for as long as Topspin exists. Reducing friction is a primary goal. However, the work done by Burning Tag in the last couple years has resulted in a highly differentiated solution. Users of Topspin’s suite of tools now are able to transact anywhere on their own site (burningtag.com vs burningtag.myshoppingcart.com). Integrations are simple – a single script tag and an anchor tag (which continues to evolve, but remains the same small-footprint embed). The presentation is robust and not very vulnerable to errant local CSS files, keeping integration light. The transaction can work anywhere – a web browser, your phone, an iPad – and on non iOS devices as well. Finally,  transactions can be started anywhere a link can be displayed. Transactions are now internet-scale. Through all of this, the number of unintentionally abandoned purchases (due to device capability or page environment) are reduced, which has helped overall conversion.