Armakuni Contact us
← All case studies

The same customer bought the gear, ran the event
and joined the club. The brand saw three strangers.

A U.S. outdoor and fitness brand, with more than $50 million in annual revenue, sells gear online and runs events nationwide, and its customer data sat in nine platforms that couldn't tell one person from another. We built a customer data platform on AWS that joins them into one profile with more than 100 attributes, and sends behavior-based audiences back to the marketing tools.

Before

Two businesses that should have been one.

Marketing guessed.

After
40%higher return on targeted campaigns
2×loyalty participation
5×engagement across channels

As the brand reported.

Two businesses that should have been one

The brand runs two closely connected businesses: selling rugged equipment online, and running events that bring customers back in person. They feed each other. An event finisher is the best prospect for better gear, and a gear buyer is the best prospect for a first event.

The systems couldn't show it. Shopify held purchases, TicketSocket held event registrations, the loyalty club had its own records, Klaviyo and Mailchimp held email, Bazaarvoice held reviews, and Facebook Ads and Google Ads held ad results. The same person could appear as five separate records, and nobody could say whether an event participant had bought the right gear, or whether a frequent shopper had ever come to an event.

So marketing guessed

Every campaign went to broad audiences, spending money on people unlikely to convert. The ad platforms optimized for whatever conversion they could see, so nobody could tell which channels brought customers who stayed. And every new audience waited on an analyst writing SQL, for days.

A single profile for each customer, sent back to marketing's tools

We built a single customer record from all nine sources, with the behavior that matters already calculated, and sent audiences back to the tools marketing already uses, so a marketer can pick a segment where "who should we target?" used to need an analyst's project.

How we built it

3 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Each source has its own connector, so one change breaks nothing else
  2. More than 100 KPIs calculated on every profile
  3. Send the audience back to where the campaign runs

Each source has its own connector, so one change breaks nothing else

Built withRedshiftGlueDynamoDBCloudWatch
One sync for every source Purchases Events Members
The engineering

A single integration for everything would break whenever one vendor changed its API. So we built API integrations to each of the nine platforms as separate services, inside a microservices architecture:

  • Each source integration runs as its own service, so a change in one platform is handled without rebuilding every connector, and a new source is configuration rather than a custom build.
  • Identity resolution reconciles email, registration and membership records into one customer profile, held in an Amazon Redshift unified model for analysis.
  • AWS Glue pipelines clean and enrich the records.
  • Queueing, backoff and retry logic handle API throttling and partial sync failures during order and registration peaks, with DynamoDB keeping high-volume identity and sync state.
  • CloudWatch shows pipeline failures, dropped records, schema drift and data-quality issues, so the team fixes them before an audience goes out.

Why: a missing customer leaves a small gap, while a customer counted twice makes every segment built on that data wrong.

More than 100 KPIs calculated on every profile

Built withQuickSight
PurchasesEvent entriesMemberships 100+ KPIs
The engineering

Instead of a new analyst query for every campaign, the platform calculates more than 100 customer KPIs on every profile: average order value, event history, time since last engagement, channel preference, product affinity and lifetime value, plus a combined engagement score across email opens, ad clicks, event registrations, purchases and loyalty activity. Those fields make segments reusable.

Amazon QuickSight gives marketing, commerce and event teams one view of acquisition, conversion and repeat behavior. Teams can look at audience suppression, loyalty participation and event performance, build segments themselves and export the targeting lists. Attribution combines paid, organic, email and event-driven acquisition per channel and per campaign, replacing the last-click view.

Send the audience back to where the campaign runs

A first-time racerKit for the next raceInvited to the next event
The engineering

The segments had to reach the tools that run the campaigns, so behavioral segments flow automatically into email and advertising platforms as audiences, and lookalike audiences are built from real behavior:

  • A first-time event participant gets different equipment recommendations from a repeat competitor.
  • Someone who finished one event is invited to the next relevant one near them, based on event history and location.
  • Purchase and engagement history decide who gets loyalty promotion, so it goes to the customers most likely to join and stay.

What we'd tell another CTO

1Resolve identity before you segment, because five records for one person make every audience wrong, and precompute the attributes marketing asks for so a segment takes minutes instead of an analyst's week.
2Give each source its own connector and plan for rate limits from the first day, with queues, backoff and retries keeping the data whole at peak. Then push the audiences back into the tools that run the campaigns. A dashboard on its own changes nothing.

What else changed

As the brand reported.

  • Customer insights 30% faster for marketing, commerce and event teams.
  • One customer view across nine platforms, with more than 100 attributes on every profile.

What comes next

Predictive lifetime-value modeling, product and event recommendations from AI, and campaigns run by AI agents that adjust targeting as behavior changes.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

Axiom would give "customer", "active" and "lifetime value" one meaning in a catalogue on Amazon DataZone, with AWS Lake Formation deciding which rows each AI agent sees. For the agentic campaigns that come next, each AI agent would get its own identity and only the tools it needs, with its rules, spend limits included, written as Cedar policies checked on every call, and hard limits on time and spend per task enforced at the gateway.

For goals that can be measured, such as conversion on an audience, AI agents would run experiments overnight inside the harness. Anything that games the score or breaks a limit would be dropped, and only a real improvement would go to the team to approve. AK Run's AI agents would take the first look at every pipeline alert and draft the fix, for a named engineer to confirm and ship with a test.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop