This blog­post is a con­tin­u­a­tion of Part 1. Please make sure you read that also to get the con­text of why the iOS App Mea­sure­ment library needs updates for iOS 5.

Tonight we are releas­ing an iOS App Mea­sure­ment update that includes a large change for clients using the default Vis­i­tor ID method that pre­vi­ously set the Vis­i­tor ID to the device’s unique iden­ti­fier (UDID).  We also fixed a bug in the Best Prac­tices Plu­gin, sec­tion 1.6 of the imple­men­ta­tion guide, that was arti­fi­cially inflat­ing pageviews.

The pur­pose of this blog­post is to notify you about the changes so you can make informed deci­sions on when you choose to update to the lat­est iOS App Mea­sure­ment release and how these changes impact your mobile ana­lyt­ics and mobile opti­miza­tion initiatives.

How will the Best Prac­tices Plu­gin fix impact my data?

The plu­gin no longer counts app starts and app returns from back­ground as a blank pageview. This will cause your over­all pageview counts to more accu­rately rep­re­sent pageviews. If you have not cur­rently imple­mented the Best Prac­tices Plu­gin or if you were fil­ter­ing out the blank pageview hits, this fix will not impact your data.

How will the default vis­i­tor ID changes impact my data?

NOTE : The default vis­i­tor ID change will impact apps using the default vis­i­tor ID only, not apps where you over­ride the default and set your own vis­i­tor ID.

Let’s start with the bad…

Since the vis­i­tor ID is the key to so many reports and cor­re­la­tions within the data, the list of reports impacted is not triv­ial.  For this rea­son, I strongly rec­om­mend you care­fully con­sider the tim­ing of your app update around your busi­ness report­ing require­ments to min­i­mize this impact.

The net impact of this update is all vis­i­tors will appear as new vis­i­tors when they update to the app ver­sion con­tain­ing this change.  Since not all vis­i­tors update apps imme­di­ately, your vis­i­tor data will be impacted dur­ing the tran­si­tion time.

I rec­om­mend tying this update to a report­ing bound­ary that makes sense for your busi­ness, i.e. first of month/quarter/year.

I also strongly rec­om­mend build­ing into your app track­ing strat­egy a method by which you have a reg­is­tered login for your apps and set that as the vis­i­tor ID when known.  If you are able to suc­cess­fully iden­tify users in your apps by the same ID as other chan­nels, you will be able to tie that vis­i­tor together across devices. Also, since this change is chang­ing on iOS first, you should be think­ing about and prepar­ing for a sim­i­lar move by the Android plat­form in the future.

Now for the goooood stuff…

We’ve removed all depen­dence on UDID from our libraries. This com­plies with Apple’s dep­re­ca­tion notice for iOS 5.

More impor­tantly, the pre­vi­ous vis­i­tor ID is not per­sis­tent with the vis­i­tor. Mean­ing if the vis­i­tor gets a new device, like I recently upgraded from the iPhone 4 to the iPhone 4S, the vis­i­tor looks like a new unique vis­i­tor on that new device. Our goal is to track a vis­i­tor across devices. The new method will do just that. The default vis­i­tor ID gen­er­ated by the library will be saved in the user defaults of the app, which gets backed up and reused on the new device, some­thing not pos­si­ble in the pre­vi­ous method using UDID as the vis­i­tor ID.

Con­versely, this also solves prob­lems with resold devices being counted as an exist­ing vis­i­tor. Even when a device is wiped clean by the new device owner, the UDID does not change on that device; there­fore, the vis­i­tor ID remained the same in the old method.  The new default vis­i­tor ID method will gen­er­ate a vis­i­tor ID for the new device owner.

More Good Stuff

We’ve heard from many of you about your strug­gles with app imple­men­ta­tion debug­ging.  We’re lis­ten­ing and work­ing on solu­tions.  If you are inter­ested in par­tic­i­pat­ing in our upcom­ing betas, please reg­is­ter here.

A spe­cial thanks to Pete, Bran­don and Will on the engi­neer­ing team and Shawn in client care for their con­tri­bu­tions to this post.

Please com­ment below with your thoughts and ques­tions on this topic.  Look for­ward to hear­ing from you.

Roger

Click Mobile Ana­lyt­ics for more Adobe Dig­i­tal Mar­ket­ing Suite goodness.

Tagged with →  
  • Chris

    Thanks for the heads-up but .… where exactly is your iOS App Mea­sure­ment library that this post refers to?

  • http://blogs.omniture.com/ Jor­gen Sorensen

    @Chris — I believe you’ve already found out by your own research, but in case any­one else is look­ing for where to down­load the iOS App­Mea­sure­ment libraries (By the way, you need to have Admin rights), you’re right, this will be help­ful infor­ma­tion to add to this article:

    Click the Admin menu at the top of your suite, select Admin Con­sole > Code Man­ager, select to gen­er­ate code for iOS(iPhone and iPad), select a Report Suite, click Gen­er­ate Code (and acknowl­edge the warn­ing), then go to the Com­po­nent Files tab to down­load the “AppMeasurement_iOS.zip” file.
    You may have noticed, there’s a file in the pack­age called “Readme-Important-Change-to-VisitorID.html” that briefly explains how the libraries were changed in response to the announce­ment of this dep­re­ca­tion by Apple. It also links to Part1 of this series, as linked in the first para­graph above.

  • http://www.buildingplotsforsale.org Land For Sale UK

    Our goal is to track a vis­i­tor across devices. The new method will do just that.