This blogpost is a continuation of Part 1. Please make sure you read that also to get the context of why the iOS App Measurement library needs updates for iOS 5.
Tonight we are releasing an iOS App Measurement update that includes a large change for clients using the default Visitor ID method that previously set the Visitor ID to the device’s unique identifier (UDID). We also fixed a bug in the Best Practices Plugin, section 1.6 of the implementation guide, that was artificially inflating pageviews.
The purpose of this blogpost is to notify you about the changes so you can make informed decisions on when you choose to update to the latest iOS App Measurement release and how these changes impact your mobile analytics and mobile optimization initiatives.
How will the Best Practices Plugin fix impact my data?
The plugin no longer counts app starts and app returns from background as a blank pageview. This will cause your overall pageview counts to more accurately represent pageviews. If you have not currently implemented the Best Practices Plugin or if you were filtering out the blank pageview hits, this fix will not impact your data.
How will the default visitor ID changes impact my data?
NOTE : The default visitor ID change will impact apps using the default visitor ID only, not apps where you override the default and set your own visitor ID.
Let’s start with the bad…
Since the visitor ID is the key to so many reports and correlations within the data, the list of reports impacted is not trivial. For this reason, I strongly recommend you carefully consider the timing of your app update around your business reporting requirements to minimize this impact.
The net impact of this update is all visitors will appear as new visitors when they update to the app version containing this change. Since not all visitors update apps immediately, your visitor data will be impacted during the transition time.
I recommend tying this update to a reporting boundary that makes sense for your business, i.e. first of month/quarter/year.
I also strongly recommend building into your app tracking strategy a method by which you have a registered login for your apps and set that as the visitor ID when known. If you are able to successfully identify users in your apps by the same ID as other channels, you will be able to tie that visitor together across devices. Also, since this change is changing on iOS first, you should be thinking about and preparing for a similar move by the Android platform in the future.
Now for the goooood stuff…
We’ve removed all dependence on UDID from our libraries. This complies with Apple’s deprecation notice for iOS 5.
More importantly, the previous visitor ID is not persistent with the visitor. Meaning if the visitor gets a new device, like I recently upgraded from the iPhone 4 to the iPhone 4S, the visitor looks like a new unique visitor on that new device. Our goal is to track a visitor across devices. The new method will do just that. The default visitor ID generated by the library will be saved in the user defaults of the app, which gets backed up and reused on the new device, something not possible in the previous method using UDID as the visitor ID.
Conversely, this also solves problems with resold devices being counted as an existing visitor. Even when a device is wiped clean by the new device owner, the UDID does not change on that device; therefore, the visitor ID remained the same in the old method. The new default visitor ID method will generate a visitor ID for the new device owner.
More Good Stuff
We’ve heard from many of you about your struggles with app implementation debugging. We’re listening and working on solutions. If you are interested in participating in our upcoming betas, please register here.
A special thanks to Pete, Brandon and Will on the engineering team and Shawn in client care for their contributions to this post.
Please comment below with your thoughts and questions on this topic. Look forward to hearing from you.
Click Mobile Analytics for more Adobe Digital Marketing Suite goodness.