Variants, alternates, labels, component

Nov 17, 2025·5 min read·TIL

Understanding Variants in the Composer / Formula Ecosystem

Version: 1.0

1. Introduction -- Why Do Variants Matter?

In Composer, a message is no longer just hard-coded text. Marketers, product teams, or automated optimisation engines need to experiment, personalise, and learn which wording performs best for different audiences.

Historically when we started building the first version of composer, Variant was used to denote the building-block that enables this flexibility.

  • Static Text (a.k.a. plain text): Immutable words that never change.
  • Variant: A slot in the text whose content can change and from which the platform can learn.

When you declare part of your copy as a Variant, you signal to the system:

  1. "This fragment is important enough to test or personalise."
  2. "Track each alternative I supply and measure its performance."

Key takeaway: A Variant is not itself the wording; it is the container (the shell) that can hold multiple alternates.

2. Glossary of Terms (Explicit & Exhaustive)

| Term | What it means (plain English) | Where it appears in data | Why it exists | |---|---|---|---| | Component | The conceptual part of a message, e.g. Greeting, Value Proposition, Call-to-Action (CTA). | Composer UI & DB | Gives authors semantic names to talk about sections of the message. | | Component Type | Enum of allowed Components. Historically called variant type. | variantType in some payloads | Classification used by Learning Pipeline to group similar pieces. | | Variant | An instantiation of a Component inside a specific message. Think "this particular Greeting here". | | Allows the system to annotate, track edits, and log performance per location. | | Variant ID | The opaque UUID that uniquely identifies one Variant shell. | variantId | | | Alternate | One concrete piece of text that can fill a Variant. Formerly "variant label text". | Separate alternates table; text field in message payload | Provides A/B (or multivariate) wording. | | Variant Edit | Historical record of edits applied to a Variant over time (append-only audit log). | variantEditId (sparse usage) | Intended for traceability; degenerated today to "points to latest Alternate only". |

Key Takeaways (TL;DR)

  1. Variant = slot, the casing, part of structure, instance; Alternate = wording inside slot.
  2. variantType == componentType (naming legacy).
    1. type is definite (enum)
      1. now customers can add type so no longer enum but limited set can be looked up in DB per customer
      2. earlier this was global
    2. variantId = componentID?
      1. does it even exist componentID
      2. variantId is just the initiation of the variant type
      3. if a message has three variant in its structure it will have three variant IDs
      4. We can call it VariantInstanceId or ComponentInstanceId if we want to
      5. A message can have one or more components along with static text and each will have ID
  3. variantId is per-slot, per-instance, label_Id is per-label; labels should be shared across alternates. (imp for learning) label can also be on formula level

Throw away variant is possible - it doesn't mean much from data model perspective

Open Question

  1. Label on formula is a hack
    1. TBD
  2. Cleaning up variantEdit and exposing component -> label data upstream would greatly simplify analytics.
    1. Variant holds a pointer to variant Edit array (this array is always of the size of 1)
    2. The Variant Edit holds a pointer to a single Alternate
    3. Refactor would be Variant pointing straight to the alternate
    4. This might need a double check - check with Ed
      1. variant ID per slot / or per-slot-per-alternate

Formula

{Greeting} {Hi} -> label 1 {Hello} -> label 2

VariantType/ComponentType: Greeting Variant Id - uuid1 VariantId - uuid1, uuid2 --> most probably its this

  1. original variant?
    • we used to call it master variant
    • the structure itself

New TLDR

  • Message is defined as a structure / formulas which has 1 or more components.
  • Components are of certain type - greeting, value prop, CTA etc (refer to composer UI). We highlight a part of text and say this is a component of type X. That text automatically becomes one alternate/variant for that component of the message.
  • A variant is an instantiation of this component.
  • So variant as a concept refers to what we say alternates + label on composer UI
  • Example
    • {Greeting}
      • Hi -> direct
      • How are you doing? -> conversational
    • We can say this message has one component(greeting) with two variants
      • Variant 1 -> text: Hi, label: direct
  • A message can have more than one component of the same type and we will have alternates for each of these components. The alternates will be tagged to labels. Labels are modelled for reusability. A direct label used in greeting 1 could also be used in another greeting component of the message.

message composer - 1 or more components

Components: greeting greeting, value prop, call to action

alternates greeting - hi, hello, hola

label - tag the alternates Value prop

  • fight against global - sustainability
  • clear out breathe easy - declutter

labels -> action component -> action set (one of the action set) we will also have timing alternates -> generation, we will learn on what do you prefer (labels/actions) and then based we basically pick an alternate. And picking an alternate we have things like diversity scores kicking in

History

  • we learn on labels

what happens when we edit an alternate?? -- ed

← All writing