Data Manager

Manage the event schema: what gets recorded, what it is called, how it is grouped, and how it is validated and transformed.

What the Data Manager is

The Data Manager is where a project's event schema lives: the list of events your SDKs send, the segments each event carries, the profile properties your people accumulate, and the rules that decide what happens to all of it on the way in.

Everything else in the product reads that schema. The display name, description and category you set here are written to the project's own event map, which is the one every other screen reads.

Six tabs, in the order you usually need them. Custom events is the list of events themselves. Event groups combines several events so they report as one. Segments manages the properties an event carries and the data type each one holds. Validations collects what the server caught coming in that did not match the plan. Transformations rewrites data as it arrives, permanently. Profile properties manages what is stored on a person rather than on an event.

Four of those tabs only appear on servers that run Drill. A core-only server shows Custom events and Event groups and nothing else, because the lifecycle statuses, the segment metadata, the validation records and the transformation engine all live in the extended plugin. Transformations additionally needs read rights on transformations, so an account without them does not see the tab at all.

The two ideas worth holding on to before you start: hiding is reversible and deleting is not, and a transformation is permanent. The rest of this guide keeps coming back to those two.

Use Cases

Find out what an event records

Someone asks what Checkout Completed actually contains, or whether a number on a dashboard means what its label says. The schema is the answer, and it takes about a minute to read.

1. Open Manage > Data Manager. You land on Custom events.
2. Find the event. The search box matches the display name, the event key and the description, so you can look it up by whichever one you know.
3. Click the row. It expands in place and shows the segments the event carries, along with any segments that have been omitted.
4. Read the row itself for the rest: the category it belongs to, its description, how many times it fired in the last 30 days, how that compares with the 30 days before, and when it was last changed and by whom.
5. For the segment data types, switch to Segments and filter by that event. Each segment lists the type it is planned as, which is what decides whether it can be charted as a number or only broken down as a list.

The event key is worth knowing about separately. The display name is yours to change at any time, but the key is what the SDK sends, so it is the one to quote when you are talking to whoever writes the tracking code. It is hidden in the table by default and can be switched on from the table's column settings.

Describe and categorize your events

Four cards across the top of Custom events count how complete the schema is: how many events there are in total, how many carry a description, how many sit in a category, and how many are unplanned.

1. Click Categorized to filter the table down to the events that still have no category, or Unplanned to filter it to the unplanned ones. The card toggles the matching dropdown, so the filter stays visible and you can clear it where the other filters live.
2. Open a row's actions and choose Edit to give one event a display name and a description. Write the description for someone who was not in the room when the event was named.
3. To sort several at once, use Select, tick the events, then Change > Category. On a core-only server that button reads Change category instead. Categories are created in the same dialog, so you do not have to set them up first.
4. Hide the events nobody should be charting. A hidden event keeps recording. It only disappears from the analytics screens, so hiding is the safe way to clean up a list without losing history.
5. Re-check the cards. They recount as you go.

Two things not to do here. Delete is not a stronger version of hide: it removes the event and all of its recorded data, permanently. And an unplanned event cannot be made visible at all: the server refuses it. Give it a lifecycle status first, which is the next use case.

Plan an event before the SDK sends it

Planning an event means writing it into the schema before any SDK sends it, so that when the data starts arriving the server already knows what it is, what it should carry, and whether it is allowed through. It is the difference between finding out what your app sends and deciding it.

1. On Custom events, choose New event. This is only available on servers that run Drill.
2. Give it the event key the SDK will send. This is the one field you cannot change afterwards, so agree it with whoever writes the tracking code first.
3. Add a display name and a description. Category, visibility and metric labels can all be set after the event exists.
4. Add the segments you expect it to carry, with the data type each one should hold. Once the event exists, mark the ones that must always be present as required by editing them on the Segments tab. A required segment that does not arrive is recorded as a validation error rather than silently ignored.
5. Leave the new event at Created while the tracking is still being built. It stays hidden from analytics screens, and anything that arrives for it is flagged as unexpected, which is exactly what you want while someone is testing.
6. When the release ships and the data looks right, move it to Live. That is the status that lets it through cleanly and makes it visible.

Approved sits between Created and Live. It stops the event from being flagged, but still keeps it out of the analytics screens, which is the state to use when tracking is confirmed working and you are waiting to turn it on for everyone.

Merge two events into one

Two releases named the same action differently, or an event key carries a customer id and has exploded into thousands of variants. A transformation rewrites that as the data arrives, without touching the app.

Read this before you start. Transformations are permanent. Data that a transformation modifies cannot be restored, and the option to delete the source events after a merge removes those events and their recorded data as well. Deleting the transformation afterwards stops it applying to anything new, but does not put back what it already changed.

1. Open Transformations and choose New transformation.
2. Under Apply to, pick Events, then choose Merge as the action. The dialog explains what each action does as you pick it.
3. Under Targets, tick the events you want folded together. If the variants share a shape rather than a list, choose Merge by regex as the action instead and give the pattern.
4. Under Result & processing, name the event they should become, or turn on Merge into an existing event to fold them into one you already have.
5. Choose what the transformation applies to. Incoming data changes only what arrives from now on and leaves your history alone. Existing data rewrites what is already stored, in the background. Admins can follow its progress in Health Manager under Mutation status. Incoming + existing does both.
6. Read the summary line at the bottom. It spells out in one sentence what you are about to do. Save when it matches your intention.

Transforming existing data rewrites the stored events in the background, so the change can take a while to show in reports, and the dialog warns about it where you choose.

FAQs

Why can I only see two tabs?

The Segments, Validations, Transformations and Profile properties tabs need a server that runs Drill. A core-only server shows Custom events and Event groups. If the other tabs are missing on a server that does have Drill, the one that hides separately is Transformations, which also needs read rights on transformations.

Why can I not make this event visible?

The server refuses to make an unplanned event visible, and the events list reports that back. Give the event a lifecycle status first, with Change status, and its visibility follows from the status you chose.

What is the difference between hiding an event and deleting it?

Hiding takes an event off the analytics screens and nothing else. It keeps recording and you can show it again. Deleting removes the event and every data point recorded against it, and cannot be undone.

My Validations tab is empty. Is validation working?

An empty tab means nothing is unresolved. Validation records are written by the server as it ingests data, so if you expect errors and see none, check with whoever administers the server that schema validation is switched on there.

Can I undo a transformation?

No. Data a transformation has modified cannot be restored. Disabling or deleting the transformation stops it applying to anything new, but what it has already changed stays changed.

Why does an event show a count of zero when I know it fired?

The count column is always the last 30 days, regardless of the date range selected elsewhere. An event that last fired before that window reads as zero.

I renamed an event and the SDK is still sending the old name. Why?

The display name and the event key are different things. Renaming changes what the product shows; the key is what the SDK sends and cannot be changed after the event is created. To change the key you either change the app, or merge the old key into the new one with a transformation.

What happens to my data if I omit a segment?

It stops being aggregated for new data, and the data already aggregated for it is deleted. This cannot be undone. On a server with Drill, the raw event data is kept, so the segment can still be queried there as text.

Related Resources