Using the the Experience API implementation enables you to serve content on both web and mobile apps from the same Dynamic Yield section, and also to create a unified customer profile across both devices by implementing identification events with matching values.
Main implementation steps
Receiving Dynamic Yield user and session IDs:
There are two ways to obtain the user and session IDs in the app:
- If the user is redirected from the site to the app, user and session IDs should be passed along with the redirect and stored in the app.
- If the user opens the app with no previously stored values, obtain the IDs by calling an empty /choose request and storing the values returned from Dynamic Yield on the app.
Storing user and session IDs within the app
Both values need to be persisted for different time periods, so each is stored a bit differently:
- Store the Dynamic Yield user ID within the app, and persist for as long as the app is installed.
- Store the Dynamic Yield session ID in the app's cache, and persist for as long as the app is in the memory (foreground or background).
Mobile-specific implementation points
To enable targeting campaign specifically to app users, we recommend that you:
- Implement a custom event in the app right after the user receives the Dynamic Yield user and session IDs (for example, an event with a name “App User”). This enables placing the user in a mobile-app-only audience.
- Add a custom page attribute to each /choose request coming from the app. This enables mobile-app-only experience targeting.
- Manage sessions without losing the user ID. When a session on the app ends and the user opens the app again, the /choose request to Dynamic Yield should still include the stored user ID, but the session ID value should be empty. The response from Dynamic Yield will contain the new session ID that should be stored on the app.
- Add the native app user-agent data to the userAgent property in the API calls. For example:
- For iOS: <application-name/126.96.36.199 CFNetwork/897.15 Darwin/17.5.0 (iPhone/6s iOS/11.3)>
- For Android: <application-name/188.8.131.52 Dalvik/2.1.0 (Linux; U; Android 5.1.1; Android SDK built for x86 Build/LMY48X)>
While using the same section for both web and mobile app offers many ways to enhance cross-device personalization, there are a few things to note if you use this approach:
- Identifying the user on both web and app does not ensure variation stickiness. The same campaign and experience could be served on desktop and app, but there is no guarantee the user will fall into the same variation on both devices due to different user and session IDs.
- Location URL reporting in the app can be different than in the web, because there are no URLs to fetch from the app.
- Campaign reporting may not be seamless if you are using client-side campaigns on the web and API on the app, because each environment has separate reporting (this is not the case if both web and app are using API campaigns).
- User allocation to audiences who have been identified with the same ID on different devices happens overnight (standard functionality).