Experience APIs enable you to serve content on both web and mobile apps from the same site, and also to create a unified customer profile across both devices by implementing identification events with matching values.
All your data and assets, such as your recommendation strategies, are centrally stored in a single site on Dynamic Yield. Your users can be referenced by a single user ID across your platforms, instead of managing different user IDs on each platform. This lets you build a more comprehensive user profile, which in turn improves our recommendation strategies and provides users with a cohesive browsing experience across all of your platforms.
For example, a user browses a product category (say, shoes) for the first time on your mobile app. On their next visit to your website, the user sees recommendations for shoes, even though this data was never accessed on the website. Note that this requires you to send an identification event every time a user logs in on a specific device (for example, their mobile phone) so that we can always recognize the same user across different devices.
Important differences between SDK and API
- SDKs render some interface elements independently, such as popups, but developers still need to render many of the other interface elements. Whereas, using APIs means that all elements must be rendered on your end.
- When you use APIs, you're responsible for the network layer and connecting to the server as needed.
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/220.127.116.11 CFNetwork/897.15 Darwin/17.5.0 (iPhone/6s iOS/11.3)>
- For Android: <application-name/18.104.22.168 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).