Transformations

Describe what your gateway changes at each checkpoint, in the same terms as the rest of your tracking plan.

A transformation records what a gateway does to events at one checkpoint. Avo applies the transformations in the order an event travels, so it can work out what each checkpoint should receive.

Define and update transformations

You write transformations through the Avo MCP on a branch, yourself or with your agent, and review and merge them like any other change. The branch diff shows each changed rule as before and after. Describe them the way you’d explain your tags to a colleague. For example:

At the Pinterest output, send transaction_id as order_id. Stop sending search_query to every ad platform output. Require tier on product views sent to Meta.

At the gateway, add event_id to every event.

Our Meta tag now sends content_ids instead of contents. Update the Meta output on a new branch.

Here’s an export of our GTM container. Compare what each tag sends with our tracking plan and add the differences as transformations on a new branch.

See Set up a gateway for the full setup.

Where a transformation can sit

An event’s shape at an output is the result of every transformation on its path: its source, then the input it entered through, then the gateway, then that output. A checkpoint with no transformation passes events through unchanged.

An input transformation doesn’t change what the source sends. It changes the event on the way into the gateway, and the event on the source still says what developers should send. Each input card on the Transformations tab says so. For a source called Web it reads “Changes on the way into the gateway. What Web sends is set on its events.” If a source should stop sending a property, change the event on that source instead of adding a transformation at the input.

What a transformation can change

The Transformations tab shows the transformations checkpoint by checkpoint, in the order they run: inputs, then the gateway, then outputs. At each checkpoint, they are grouped by what they touch (events, properties or bundles) and by what they do: Added, Required, Changed or Dropped.

Each checkpoint is set to All sent or Allow list, separately for events and properties. With All sent (the default), everything that arrives passes on, apart from what a rule drops. With Allow list, only what’s on the list passes. See Choose what passes through.

Events

• Changed. The event is sent under a different name from this checkpoint on, for example Order Completed sent to Meta as Purchase.
• Dropped. At a checkpoint set to Allow list, events that aren’t on the list don’t get through from here on. An event on the list keeps all its variants. Renaming an event doesn’t put it on the list.

Properties

A property rule applies to every event at the checkpoint that carries the property.

• Added (enrich in the MCP). The gateway adds the property to every event, not only the ones that already send it. Use it for values the gateway fills in, such as a click id read from a cookie. It’s always sent, unless you mark it sometimes sent.
• Required (require). Every event that reaches this checkpoint must already carry the property. The gateway never adds it, so the sources that feed the checkpoint have to. For example, if a Meta audience is built on tier, requiring tier at the Meta output says that every product view reaching Meta must carry it. If a source doesn’t send tier, that’s the gap to fix at the source.
• Changed (tighten). The property is modified only where it already arrives, and never added. At a checkpoint set to Allow list, a property that’s on the list with no change keeps arriving where it’s already sent. A change can:
  • Rename the property, for example transaction_id sent as order_id.
  • Change its presence by marking it sometimes sent.
  • Constrain its value:
    • Pin it to one value.
    • Refine its allowed values by ruling out values it otherwise allows.
    • Require a regex.
• Dropped. The property doesn’t get through from this checkpoint on. This holds when the property arrives inside a bundle too, and the bundle’s other properties are still sent. Dropping is different from clearing a rule: clearing removes this checkpoint’s rule, so the property goes back to what it inherits from earlier checkpoints.

An Added, Required or Changed rule can rename the property and pin its value as well.

Property bundles

• Added. This checkpoint adds a property bundle, so all its properties are sent from here on, including ones no rule names.
• Dropped. The bundle’s properties don’t get through from this checkpoint on.

More transformation types are coming. If you’re missing one, let us know at support@avo.app or in the chat bubble in the app.

Avo is the analytics governance platform for product data that lets you define it consistently, implement it correctly and trust it everywhere. Using an AI agent? Connect it to the Avo MCP at https://mcp.avo.app/mcp and it can write these transformations for you on a branch and tell you what an event looks like after them.