The Medio Platform is designed to be very flexible but we have a few basic rules and recommendations that you should follow in order to get the most out it.
Event type names
For readability and consistency, we require that you name event types according to three simple rules:
- Event type names must be less than 64 characters long.
- Event type names must begin with an alphabetical character (uppercase or lowercase).
- Non-alphabetical characters in event type names must be limited to numbers ([0-9]), periods (‘.’), hyphens (‘-’), and underscores (‘_’).
Here are a few tips when thinking about how to name your events:
- Strive to make your event type names as short as possible without introducing ambiguity. Feel free to use abbreviations and acronyms.
- If you think that you might change the schema of an event in the future — by adding or removing key-value pairs — consider appending a version number to your event type name. For example, an event type named ‘purchase’ could be named ‘purchase-1′ to indicate that it follows version 1 of your schema. Using versions for event type names helps to avoid problems in processing or reporting on data that have different schemas.
- If you choose to append a version to your event type names, use a version that is independent of your product version. The version is used to indicate the schema of your event, which you may want to keep the same across multiple versions of your product.
When using the SDKs, we recommend that you use the automatic flush mode to send events to Medio Data Collection Service. Automatic flushing provides the best balance between maintaining application performance, preserving device battery life, and avoiding event data loss or delay. If you choose to disable automatic flushing, you should carefully consider how often you manually flush your application’s events. If you flush infrequently, your events may arrive late or may be lost if you exceed the capacity of the SDK’s internal event buffer. If you flush too frequently, you may drain the device’s battery and your users’ experience in your application may be disrupted.
The SDKs automatically generate an anonymous ID for each user that stays the same across your application’s restarts. If your application manages its own user identifiers — say, if your application allows users to log in with a unique username &mdahs; then you can use the SDK to send that user identifier with each event. This allows you to associate all events that you log with a specific user, even across multiple devices and applications.
Note that we store your application’s user ID in plain text, so depending on your organization’s privacy policies and/or statutory requirements, please consider how to best manage your users’ privacy. We recommend that you hash user IDs before setting them if they contain any personally identifiable information.
You can log a maximum of 255 key-value pairs with each event. Keep in mind the following rules when logging key-value pairs:
- Key names must not contain an equal sign (‘=’).
- Key names must not begin with underscores (“__”).
- A key-value pair with a null key name will be ignored.
- A key-value pair with a null value will be converted to a value containing the string “null”.
What to log
When thinking about what user activities to log within your application, try to imagine recreating your users’ experiences based on the sequence of events that you’ve logged. It’s always best to err on the side of logging more activities than you think you need. Even if a user activity seems insignificant to you now, it may provide unforeseen insights into your users’ behavior in the future.