By now, most developers know that iOS 14’s new privacy permissions will probably impact the way apps learn about their users. To help developers understand their users while respecting user-privacy and Apple’s new rules, we’ve introduced new features into Pilgrim SDK.
The iOS 14 rollout brings with it two critical elements that will undoubtedly necessitate some adjustments on the developer side:
- A new era of identity: IDFAs may fade and give rise to new identity alternatives
- Shifts from “Precise” to “Approximate” location-sharing: New permissions give consumers more control over how/when their data is collected by apps
The new-and-improved Pilgrim SDK (aka Pilgrim SDK 3.0) offers support that directly tackles each of these issues while also addressing another persistent pain point SDK customers may have experienced: easy access to Pilgrim data via AWS S3.
Here’s a deeper dive into each of the new support features we’re introducing with Pilgrim SDK 3.0:
Support for Multiple Unique Identifiers
The upcoming iOS 14 privacy changes will allow users to opt-out of sharing their IDFA – which will prevent their activity from being tracked across the web. For app developers, this presents a challenge because the IDFA may also be the ID that’s used to understand user behavior that’s unrelated to any ad activity.
To solve this challenge, Pilgrim will now support new forms of ID that emerge to replace IDFAs. As a result, developers will still be able to tie Pilgrim events to a specific user with an ID of the developer’s choice (e.g. a phone number email address, or a proprietary ID). Of course, you’ll still need to request permission from your users to use this alternative ID – which is why it’s important to explain exactly how this data is being used through your onboarding experience or primer message. (Read more here for more info on how to set custom user unique identifiers.)
User State Improvements
For years, Pilgrim’s User States has offered insights into how a user is moving – like when an app user is traveling, commuting, or entering a specific geofence. With this information, developers can push notifications based on where a user is. Now that users have the option to share approximate location, developers could lose that level of specificity when triggering notifications. Within Pilgrim SDK 3.0, we’ve enhanced our User States functionality to deliver events to apps telling them the city, DMA, state, country, and zip code that their user is in and when any of that state changes. This is valuable for all users but especially those that are sharing approximate location where we’re unable to detect other user states. Although limited, this location context can still be used to trigger notifications and provide insights about your users. (Read more here for more info on how to accurately interact (or not interact) with your users based on their state.)
Export Pilgrim Data to S3
Until today, developers looking to access and store Pilgrim data faced a daunting process: capture each webhook and ingest that data in real-time. This process makes sense (and is worth it) for developers in need of real-time updates – but for developers not looking for real-time updates, the process could be time-consuming.
We set out to make that process easier so that developers can store and analyze their data without needing to rely on a developer for help. We’re now offering an AWS S3 export option that allows you to securely store your data in an S3 bucket. Simply log to the Pilgrim Dev Console, add your S3 bucket path test, save, the data is delivered daily – no engineering work required! (Read more here for instructions on how to configure an S3 bucket to ingest Pilgrim data).
Pilgrim SDK 3.0 is available today. For more information, reach out to Foursquare or check out our Pilgrim SDK developer docs.
