Rearchitecting Client Events at Stitch Fix

Rob Wierzbowski

Stitch Fix is a data-driven company

Track the user's experience

Route loads, views and clicks

Real-time personalization

Measure KPIs

Guide business decisions

CLient events

Setting the stage

No centralized responsible party to vet event requirements.

No standardization of event schemas. Teams created new event schemas for most features and use cases.

No standardization of event triggers. Events were triggered in different layers of an application, with different heuristics and success ratios (e.g., a screen load event sent from a SPA on route load, or from the backend on route request).

Complicated, non-standardized contextual data was added to each event. Often known as “subsource”, it could contain information about UI near the event trigger, site region (e.g., checkout, product page), actions the client took in the past, and even other subsources.

Low to zero feedback loop on event impact after implementation

Major Issues

No centralized responsible party to vet event requirements.

No standardization of event schemas. Teams created new event schemas for most features and use cases.

No standardization of event triggers. Events were triggered in different layers of an application, with different heuristics and success ratios (e.g., a screen load event sent from a SPA on route load, or from the backend on route request).

Complicated, non-standardized contextual data was added to each event. Often known as “subsource”, it could contain information about UI near the event trigger, site region (e.g., checkout, product page), actions the client took in the past, and even other subsources.

Low to zero feedback loop on event impact after implementation

Major Issues

Doubled time to feature completion. Teams reported spending 50% of feature development time on Client Events, up from negligible with GA.

Stressful negotiation of event data. Many event context requests involved large lifts, which engineers resisted.

Highly coupled app code. Event values were passed deeply through component trees, creating frustrating spaghetti codebases.

Increased maintenance costs, with causes including databases to support event context, maintaining unused events, and refactoring friction due to coupled code.

Low ability to analyze events across teams, due to non-standard event shapes.

Incorrect KPI and personalization results caused by frequent bugs. Testing was difficult and errors were often unnoticed.

Major Impacts

Doubled time to feature completion. Teams reported spending 50% of feature development time on Client Events, up from negligible with GA.

Stressful negotiation of event data. Many event context requests involved large lifts, which engineers resisted.

Highly coupled app code. Event values were passed deeply through component trees, creating frustrating spaghetti codebases.

Increased maintenance costs, with causes including databases to support event context, maintaining unused events, and refactoring friction due to coupled code.

Low ability to analyze events across teams, due to non-standard event shapes.

Incorrect KPI and personalization results caused by frequent bugs. Testing was difficult and errors were often unnoticed.

Major Impacts

Solve: Rearchitecting Client Events

• Increase standardization
• Reduce time per feature
• Balance responsibilities between Eng and Algos orgs

Goals

• Business critical actions and entities:
  • View and Click (Select)
  • Routes (Screens), Categories, Outfits, SKUs, Generics
• Minimal, atomic events
• Strict definitions; unions where possible
• TypeScript compiled into JSON Schema for transport

Strongly typed schemas

Strongly typed schemas

• Distributed tool to send events from frontend apps
• Well documented, fully featured (test helpers, bug tracker integration, etc)
• Optimizes transport and triggers
• Automates event contex

Event Reporter

Event reporter

• Intersection Observers trigger an event when 60% of a component is in viewport, or when the component covers 30% of the available viewport
• Transport via keepalive Fetch
• Batching and Gzip for performant bytes over wire

Event reporter

Event Reporter

• Validation
• Security
• Message transportation (RabbitMQ)

Client Event Service

• A long process
• Many revisions in the early stages
• Thin implementations
• Parellel implementations
• Building support from the ground up

Rollout

• Client Event implementation has fallen to 10-15% of feature time. Reducing time and stress around events was by far our biggest goal, and teams using the new architecture report great success. Event content negotiation time has fallen by 90%.

• Teams are decoupling components, increasing isolation, reuse, and test coverage with Event Reporter.

• Communication is improved and responsibility is clear. Questions and discussions are handled efficiently, and teams share well-defined, standardized nomenclature around Client Events.

• Algos can analyze data across all client facing apps. New events have flexibility that will lead to improved analysis over time.

• Bespoke Algos pipelines and event processing are being removed.

• Personalization and KPI report accuracy has improved due to improved testing, strict schemas, and multiple validation layers.

• We have not lost significant analysis ability by switching to a simplified event context.

Impact

Discussion