Adobe
Adobe Digital Marketing Blog
  • Digital Marketing
    • Mobile
    • Social Media
    • Digital Advertising
    • Search Engine Marketing
  • Analytics
  • Personalization
  • Industries
    • Financial Services
    • Media & Entertainment
    • Retail & Travel
  • Executive Insights
    • Aseem Chandra
And the eCommerce Black Friday & Cyber Monday Winner is … Mobile! Enhancing automatic exit links

An Early Adopter’s Perspective on the Omniture APIs — Q&A with Gary Angel, President of Semphonic

Digital Marketing · By Jeff Minich On January 3, 2010 · Leave a Comment

Gary Angel, Pres­i­dent and CTO of Sem­phonic, a Web ana­lyt­ics con­sul­tancy, recently hosted an Omni­ture Devel­oper Con­nec­tion User Group in San Fran­cisco. Gary co-founded Sem­phonic and leads their con­sult­ing efforts for com­pa­nies like Amer­i­can Express, Charles Schwab, Intuit, Genen­tech, Nokia, Sears and Turner Broad­cast­ing. Gary has pub­lished arti­cles on Web and SEM Ana­lyt­ics in DM News, Amer­i­can Demo­graph­ics, CRM Guru, CRM Buyer, IMe­di­a­Con­nec­tion, Busi­ness Geo­graph­ics and Busi­ness Insur­ance. As an early-adopter of the Omni­ture APIs, Sem­phonic has been build­ing inte­grated solu­tions that com­bine Web ana­lyt­ics with enter­prise data to help cus­tomers real­ize new mar­ket­ing inno­va­tion and effi­ciency through the Omni­ture plat­form. After the San Fran­cisco User Group, Gary and I con­nected to talk more about Semphonic’s use of the Omni­ture APIs:

Q:  At the Omni­ture devel­oper user group, you men­tioned that cus­tomers are pulling you into inte­gra­tion projects that really advance beyond cur­rent web ana­lyt­ics par­a­digms. What are cus­tomers ask­ing you to inte­grate and why?

A: One of the things that make inte­gra­tion projects chal­leng­ing is that they tend to be pretty unique. I guess I’d say that inte­gra­tions tend to fall into one of three basic types. The most com­mon is prob­a­bly the inte­gra­tion of mul­ti­ple man­age­ment report­ing streams. The vast major­ity of our cus­tomers are multi-channel. For many of them, their source of ulti­mate truth are CRM and finan­cial sys­tems – and data from these sys­tems forms the bulk of what gets reported up to senior man­age­ment. But the top end of the fun­nel – where online behav­ior occurs – needs to be rep­re­sented there as well. The API makes it pos­si­ble to pull that online behav­ioral infor­ma­tion at the same time as you are tap­ping into these other sys­tems – and push­ing the infor­ma­tion into a sin­gle uni­fied (and auto­mated) report. The sec­ond type of inte­gra­tion, less com­mon but to me more inter­est­ing, is when we pull infor­ma­tion so that we can ana­lyze it in more detail. In a way, our SAINT appli­ca­tions are like that – we take advan­tage of the full-feature reg­u­lar expres­sion libraries in .Net to built rule-based SAINT tables auto­mat­i­cally – some­thing that just isn’t pos­si­ble oth­er­wise. Finally, we’ve worked on a few inte­gra­tions where the goal was sim­ply to pull data out of the ana­lyt­ics and into some piece of an online sys­tem (usu­ally to push or opti­mize some part of con­tent). That’s use­ful but also very pro­vi­sional – ulti­mately you’d hope that peo­ple use more com­plete tools for that kind of work.

Q: For those who aren’t famil­iar with the SAINT (Site­Cat­a­lyst Attribute Import­ing and Nam­ing Tool) API, can you share an exam­ple of the kind of data you use it for and why?

A: SAINT is used to gen­er­ate lookup tables in Site­Cat­a­lyst. Prob­a­bly the most com­mon use is for com­pa­nies to assign friendly names and rollup cat­e­gories to cam­paigns based on a cam­paign code cap­tured from the URL. But it can be used for almost any kind of vari­able. Our clients often use SAINT tables for prod­ucts and mer­chan­dis­ing cat­e­gories, arti­cle names, video meta­data and more. This all works fine where you con­trol the meta­data that comes in (like prod­uct id to prod­uct name). But it’s nice to be able to cat­e­go­rize exter­nal vari­ables as well — things like SEO key­words, arti­cle tags, and inter­nal search key­words. To effec­tively ana­lyze any of these, you need to cat­e­go­rize them. In the­ory, SAINT let’s you do this. But SAINT tables are strictly a 1-to-1 lookup. You can’t apply any logic like “if the key­word phrase con­tains XXX assign it to Y Cat­e­gory.” That makes SAINT very dif­fi­cult and man­ual for this type of appli­ca­tion. We use the SAINT API to pull all the val­ues from a Site­Cat­a­lyst vari­able and then apply a series of reg­u­lar expres­sion or lookup rules to cat­e­go­rize each value — then auto­mat­i­cally gen­er­ate the SAINT table. It’s almost the only prac­ti­cal way to do analy­sis on large open-ended fields like SEO key­words or inter­nal search key­words and it’s also very use­ful for sophis­ti­cated SEO reporting.

Q: Sem­phonic was a very-early-adopter of the Omni­ture APIs. In your blog, you write about the increas­ing matu­rity of the Omni­ture APIs. Where have you seen improve­ments and how is that help­ing you serve cus­tomer needs better?

A: It has improved a lot – and in many of the ways you’d most expect as a soft­ware sys­tem achieves matu­rity. The doc­u­men­ta­tion and exam­ples are a lot bet­ter now. That’s a big deal when you’re first start­ing out with a new soft­ware tool. We hap­pen to be a .Net shop, and when we first got started the secu­rity model was just a killer. It took for­ever just to fig­ure out how to authen­ti­cate. That’s really frus­trat­ing of course because you feel like you’re just spin­ning your wheels. It’s also really hard, as a con­sult­ing firm, to jus­tify those hours. You can’t tell a client you couldn’t fig­ure out how to logon to the sys­tem – so you end up hav­ing to eat all those “edu­ca­tional” hours. Now there are good exam­ples that make this pretty easy. The extent of the APIs has also improved a lot. The cov­er­age is pretty darn good now. Finally, the cost model and token model have improved and been clarified.

Q: What would you like to see on the roadmap for the Omni­ture APIs?

A: Like most devel­op­ers, I’d still like to see a throt­tling mech­a­nism as opposed to the cur­rent token mech­a­nism for con­trol­ling usage. I’ve also cam­paigned for a sys­tem where 3rd Par­ties like us could buy tokens and use them for cus­tom apps to sim­plify our client arrange­ments. In terms of the APIs them­selves, I guess I’d like to see direct access to the event level data ala the Data Feed. I think it would be great to be able to cus­tomize and launch data feed requests and get back that true server-call level data.

Q: How do you see cus­tomer require­ments evolv­ing, Vis a Vis Web ana­lyt­ics inte­gra­tion with multi-channel mar­ket­ing efforts, in 2010?

A: At the upper-end of the matu­rity curve I think 2010 is going to see a lot of move­ment on the customer-level inte­gra­tion of web ana­lyt­ics data. To be hon­est, I thought a lot of this would hap­pen in 2009, but it was such a tough year for big projects that I think most orga­ni­za­tions ended up just push­ing these types of projects out. My sense is that lot’s of com­pa­nies are ready to com­bine key online events with their other customer/visitor data. Doing that often means mov­ing data in both direc­tions: cer­tain kinds of cus­tomer data need to move out to the web ana­lyt­ics solu­tion so that you can under­stand who you’re pro­fil­ing and what their online behav­ior means. Then, as behav­ior man­i­fests itself online, you need to be able to move that data back into your CRM and mar­ket­ing ware­house sys­tems for out­bound messaging.

Q: What’s the most inter­est­ing use of Web ana­lyt­ics data you’ve seen, out­side the report­ing envi­ron­ment of Sitecatalyst?

A:  I have two ways of answer­ing this ques­tion. The most “pow­er­ful” uses of web ana­lyt­ics data I’ve seen are usu­ally inte­gra­tions that take advan­tage of event-based mar­ket­ing. Vis­i­tor X did this online – respond with these changes to the site, this out­bound email, this cus­tomer com­mu­niqué. This is pow­er­ful stuff and it takes a lot of mar­ket­ing oper­a­tions work – but truth to tell it’s not that inter­est­ing ana­lyt­i­cally. It’s usu­ally just cherry-picking – because the best oppor­tu­ni­ties for this kind of inte­gra­tion are obvi­ous. Ana­lyt­i­cally, I con­tinue to believe that one of the most inter­est­ing ana­lyt­ics projects we do is full behav­ioral seg­men­ta­tion. Typ­i­cally, we take a full Omni­ture data feed for a month or two and then build behav­ioral pro­files of every vis­i­tor in tools like SPSS or SAS using clus­ter analy­sis. When we can, we’ll also inte­grate online sur­vey data. This type of behav­ioral pro­fil­ing is fas­ci­nat­ing work – but I also think it’s gen­uinely pow­er­ful. It’s the best way I’ve found to make web ana­lyt­ics data actu­ally come alive for marketers.

Q: You’ve recently been writ­ing about appli­ca­tion mea­sure­ment and how that’s dif­fer­ent than Web Ana­lyt­ics. As more apps move into the cloud, what should devel­op­ers be think­ing about in terms of mea­sur­ing their applications?

A: I wrote five long blogs on this — so it’s a chal­lenge to shrink it down to a bite-sized answer. But here are a cou­ple big-picture things. First, you’ll find that mea­sur­ing appli­ca­tions requires a pretty fun­da­men­tal shift in mea­sure­ment think­ing. The basic web site mea­sure­ment stuff (pages,
clicks) really don’t apply. Instead, you need to think about cap­tur­ing func­tional usage, appli­ca­tion states, and per­for­mance infor­ma­tion. Unfor­tu­nately, you still need to trans­late this par­a­digm back into some­thing that works in the ana­lytic solu­tion and that can be pretty dif­fi­cult. It’s also impor­tant for devel­op­ers to real­ize that mea­sure­ment inte­gra­tion takes real plan­ning and test­ing cycles — and there aren’t sim­ple auto­mated solu­tions for test­ing. So it’s vitally impor­tant to inte­grate the mea­sure­ment into the early stages of devel­op­ment and build a care­ful test-plan — oth­er­wise you’re likely to end up leav­ing most of the impor­tant mea­sure­ment on the app cutting-room floor.

Q: What advice would you give to a new Omni­ture Developer?

A: If you’re pick­ing an envi­ron­ment, PHP is the best sup­ported and doc­u­mented. Def­i­nitely start with one of the sam­ple pro­grams in the gallery – obvi­ously you should pick one from your envi­ron­ment. I find it’s just a lot eas­ier to get started when you can begin by mak­ing tweaks to exist­ing code that com­piles and works. I also think it’s worth start­ing with the Site­Cat­a­lyst Report­ing APIs – or at least under­stand­ing them – even if you’re focused else­where. I find we end up using these even when we are doing an appli­ca­tion mainly focused on some­thing else (SAINT for instance). Site­Cat­a­lyst is still at the heart of the envi­ron­ment and those APIs are def­i­nitely worth under­stand­ing.

  • Follow Adobe Digital Marketing

    Fol­low @AdobeDigMktg
  • Popular Posts

    • Excellent Blog Post — Getting More from your Omniture Implementation.4
    • Tim Tebow and Mobile Marketing in 2012 (Part 1)2
    • Change the Conversation: What does “Efficiency” really mean?2
    • My work, My passion — Customer Analytics1
    Adobe Digital Marketing Blog

    Pages

    • Digital Marketing
    • Analytics
    • Personalization
    • Industries
    • Executive Insights

    The Latest

    • Using Dependent Code: Adding the Twitter Handle Name to Your Referring Traffic
      A common request I hear from customers is the desire to integrate […]

    More

    See how Adobe is changing the world through digital experiences. We are the leader in delivering solutions that let customers produce, distribute, and realize value from great content, whether in media and publishing or digital marketing.
    © 2012 Adobe Systems Incorporated. All Rights Reserved.
    Tweet