Unlock the Power of Custom Datastreams for Your Mobile Apps: Elevate Your Data Collection Strategy

[#1]

Applications frequently face scenarios where the single standard datastream setup isn't sufficient to meet specific use case requirements. Whether it's refining data consumption, integrating custom processing logic within mobile apps, or managing the mobile app code release cycle, adjustments are often necessary. This discussion explores methods for modifying and overriding default datastream configurations by leveraging Data Collection (Tags), eliminating reliance on the mobile app code push cycle. As a result, updates to the datastream override can be implemented rapidly without going through the mobile app release process. The key benefit is the ability to configure datastream overrides at the Data Collection (Tags) level, rather than within the mobile app itself. 

Additional Use Cases: There are various scenarios where your app may require adjustments to its datastream or dataset override configuration. In this blog, I will highlight a few key use cases to demonstrate when and why such modifications might be necessary. 

• Dynamic data routing: Mobile apps that use the AEP Edge with multiple services (Analytics, Target, Platform, Audience Manager) can selectively forward data for different events, e.g. send marketing events only to Analytics, exclude low-value or "noise" events from Platform etc, ensuring more precise data collection. 

• Regional or Business Unit Routing: A global app may need to send data to country/region-specific datastreams based on user location. Datastream overrides allow routing to different report suites, schemas, and datasets per region or business unit. 

• Power User Upsell Campaigns: Using datastream configuration overrides, you can send key product usage events (such as feature usage by active users) to a profile-enabled dataset for segmentation and personalization. Meanwhile, routine usage data from all users is routed only to a reporting dataset for analytics, keeping your segmentation precise and your reporting data efficient. 

• Implementing Privacy Choices: You need to respect user privacy choices and prevent data from being sent to certain Adobe services based on their consent preferences. 

We will examine how to override datastreams on the client side using Tags by assigning different datastreams to production, staging, and development environments. 

Development Steps: 

We often face situations where the Application ID lacks consistency, so we can use the Environment File ID (populated by app developers) to differentiate build instances (Development, Staging, Production). Instead of relying on complex logic with multiple conditional checks on the Application ID—such as determining if it contains specific values—this approach directly accesses the Environment File ID, which remains consistent across builds. By using this method, we streamline the process and ensure reliability in distinguishing different instances. 

1. Create a Data Element designed to retrieve the Environment File ID (set by app developers) allowing us to differentiate between the development and production instances of the app. 

• Assuming this is how the mobile app developers have passed the environmentID  

• Create and name the data element “environmentID” 

• Choose extension Mobile Core and Data Element Type as freeform  

• Path key should be freeform type, set to “data.__adobe.analytics.contextData.environmentID” 

 2. Create a rule that will check for a specific AEP request, Environment File ID (dev vs stage vs prod) instance and configuration override      settings. 

• Create a rule and name it “DatastreamOverride for Edge Send Event Calls - dev". 

• Use AEP Edge Network as the Extension and add Event Type “AEP Request Event". Add XDM Event Type in alignment with your use case requirement for the override. 

• Check the logic type using the data element “environmentID”, created in the previous step, whether it belongs to dev vs prod instance. 

• Use Mobile Core extension and Action type as “Attach Data” and add the JSON payload as follows: 

{ 

    "config": { 

        "datastreamIdOverride": "[Datastream ID]" 

    } 

} 

 3. Verify in Assurance: 

• Connect your app to Assurance for testing. 

• Add Event Transactions and Data Elements through Configuration options on the left of the screen in Assurance tab. 

• Inspect the values returned by your data element, as well as your Edge calls in Event Transactions.  

• Look at the datastream ID to confirm your override settings. 

Gotcha’s: 

• If you aim to distinguish between your development, staging, and production app instances using the ApplicationID, note that ApplicationID value is reliably present only for Application foreground events. To use ApplicationID for all other AEP events, mobile app developers must explicitly pass it in the designated schema field group. 

• Dynamic Datastream Configuration overrides can also be applied at the datastream level. This server-side datastream configuration feature is currently available in beta. 

Conclusion: 

Appropriate Tags implementation gives you the power to manage datastreams directly outside of app release cycles. This process unlocks a variety of use cases ensuring your implementation is customized to your specific business needs.