Evaluate Ophan tracking approach for NewsletterSignupInline vs EmailSignUp

[georgerichmond]

Summary

We are introducing a new inline newsletter signup component, NewsletterSignupInline, to replace the existing EmailSignUp experience in EmailSignupWrapper.

We need to work with the Ophan team to define the best way to track the new component separately from the existing one, so we can compare performance and keep reporting clean during the migration.

Context

The current EmailSignUp component is already tracked in Ophan, and the new inline version will likely need:

• distinct impression tracking
• distinct click / CTA tracking
• separation between old and new component performance
• a way to identify whether the user saw the legacy or inline experience
• a way to track fallback states, if relevant

Current DCR patterns

DCR currently uses:

• data-component for automatic Ophan component tracking
• data-link-name for click tracking
• explicit ComponentEvent payloads for more detailed event tracking

Existing patterns suggest that component naming and event ids should be stable and descriptive, especially when we want to compare variants or versions.

Goals

We want to decide:

1. how the new inline component should be identified in Ophan
2. how to distinguish it from the existing EmailSignUp tracking
3. whether the tracking should be split by component name, event id, labels, or some other convention
4. how to represent legacy vs new component in dashboards during rollout
5. whether the same approach should work if the component later changes again

Options to evaluate

Option 1: Separate data-component values

Track the new component with a distinct data-component name, such as:

• newsletter-signup-inline
• newsletter-signup-inline-v2

...and keep the old component as:

• email-signup
• email-signup-wrapper

Option 2: Separate explicit Ophan event ids

Keep the rendered component tracking stable, but use new explicit ComponentEvent.id values for the inline version and its interactions, such as:

• newsletter-signup-inline-view
• newsletter-signup-inline-preview
• newsletter-signup-inline-signup
• newsletter-signup-inline-success

Option 3: Hybrid approach

Use both:

• a distinct data-component name
• distinct ComponentEvent.id values
• specific data-link-name values for CTAs

Questions for the Ophan team

1. Is data-component the right place to distinguish the new inline component from the old EmailSignUp component?
2. Should the old and new versions have separate component names, or should we preserve one stable name and use labels / event ids?
3. What naming convention do you recommend for tracking a component replacement like this?
4. How should we track the difference between:
   • inline component impression
   • preview modal open
   • CTA click
   • signup success
5. If we need to track fallback newsletter selection, should that be a label, a component id suffix, or a separate event?
6. What would make reporting and comparison easiest in Ophan during rollout?

Proposed output from this ticket

• Agreed tracking strategy for old vs new newsletter signup component
• Agreed naming convention for data-component, data-link-name, and/or ComponentEvent.id
• Clear recommendation from Ophan on the best way to keep legacy and new component reporting separate
• A follow-up implementation ticket with the final agreed event names

Acceptance criteria

• We have reviewed the available tracking options with the Ophan team
• We have a recommendation for how to distinguish NewsletterSignupInline from EmailSignUp in Ophan
• We know which fields should be used for:
  • impression tracking
  • click tracking
  • signup success tracking
  • fallback/variant tracking if needed
• The agreed approach is documented for implementation