Capture event and session properties for mobile frontends
- Latest Dynatrace
- How-to guide
Use event and session properties to enrich your RUM data with business or application context and tailor monitoring to your goals. You can work with them in the following ways:
- Report properties via the API—send any data available in your application as event or session properties.
- Enrich properties in OpenPipeline—aggregate session properties from event properties or set the user identifier during ingest.
Report properties via the API
To prevent unconfigured properties from being dropped during ingest, you must allow each property.
Allow API-reported properties
To allow a reported property
- Go to
Experience Vitals > Overview. - Select Mobile to view all mobile frontends.
- Select the frontend you want to configure.
- In the Settings tab, select Capture properties.
- In the Allowed API-reported properties section, select New property.
- Enter the property key.
- If you want the property key validation to ignore case, turn on Property key validation should be case-insensitive.
Send event and session properties
Event and session properties can be sent via the New RUM APIs:
- To add event properties, use
addEventModifier. - To send a session property, use
sendSessionPropertyEvent.
Aggregate session properties from event properties
Session properties can be derived from event properties and aggregated across a session using OpenPipeline. For each session property, you choose how the values reported during the session are aggregated:
- For any property type, you can keep the First or the Last reported value. Last is the default.
- For numeric properties, you can additionally use Min, Max, Avg, or Sum.
To aggregate a session property from event properties
-
Go to
Settings > Process and contextualize > OpenPipeline > User events > Pipelines. -
Select an existing pipeline or create a new one. To create a new pipeline, select Pipeline and enter a name.
-
Go to Processing > Add (or if processors are already defined) > DQL and define the processor:
-
A descriptive name—for example,
Derive session property from cart value -
The matching condition—a filter for events that carry the event property, for example:
isNotNull(event_properties.cart.total_value) -
The DQL processor definition—two
fieldsAddstatements: the first writes the event property value into the session property namespace, and the second declares the aggregation method, for example:fieldsAdd session_properties.cart.total_value = event_properties.cart.total_value,session_properties_aggregation.cart.total_value = "Max"The aggregation value is a string. Valid values are
"First","Last","Min","Max","Avg", and"Sum"."Min","Max","Avg", and"Sum"apply only to numeric properties. You can omit the aggregationfieldsAddline to use the default ("Last").
-
Enrich the user identifier from event properties
You can populate the user identifier of a session from a captured or reported event property using OpenPipeline. This lets you set the user identifier from application data, as an alternative to calling the identifyUser API method.
To populate the user identifier from an event property
-
Go to
Settings > Process and contextualize > OpenPipeline > User events > Pipelines. -
Select an existing pipeline or create a new one. To create a new pipeline, select Pipeline and enter a name.
-
Go to Processing > Add (or if processors are already defined) > DQL and define the processor:
-
A descriptive name—for example,
Set user identifier from username -
The matching condition—a filter for events that carry the event property, for example:
isNotNull(event_properties.username) -
The DQL processor definition:
fieldsAdd user.identifier = event_properties.username
You might see a warning because
user.identifieris part of the predefinedbuiltin-sensitive-user-events-and-sessionsfieldset. You can still use it for enrichment. For details about access control for sensitive fields, see Field permissions. -
Limits
The following limits apply to event and session properties:
- A field name can have a maximum length of 100 characters, including the
event_properties.orsession_properties.prefix. - A field name can contain only letters (
A–Z,a–z), numbers (0–9), underscores (_), and dots (.). For example:event_properties.cart.total_value. - You can allow up to 200 API-reported properties per frontend.
- You can send up to 50 properties per event.
- You can include up to 500 session properties per session.
- Property values must be of a primitive type:
String,Int,Long,Double, orBoolean. - String values can have a maximum length of 1,000 characters.