Building Amazon Pay's push notification engine to 5MM MAU
A first-hand look at turning push notifications from campaign execution into a lifecycle marketing system across a large Amazon Pay customer base.
Built Amazon Pay's push notification engine and scaled it to 5MM MAU in 6 months.
Lifecycle marketing becomes a growth system when eligibility, relevance, timing, frequency and measurement are designed together.
This case is written to show the problem, reasoning, operating choices and measurement logic behind the work. The objective is to make the decisions visible, not turn one outcome into a generic success story.
What was actually stuck?
Amazon Pay had a large and growing set of customer use cases. The marketing challenge was not simply sending more messages. It was building a repeatable way to reach the right customer with the right use case without turning the channel into noise.
What did the evidence suggest?
The constraint was relevance at scale. A broadcast model treats customers as one audience. A useful lifecycle system needs to recognise where a customer is in their journey, what they have already used, what they may need next, and how much communication they can reasonably absorb.
From diagnosis to intervention.
Mapped use cases and customer journeys across payments, bills, travel, entertainment, insurance and mobility.
Built audience and eligibility logic around customer behaviour rather than one-size-fits-all campaign calendars.
Created message and offer structures for acquisition, first use, repeat use and cross-sell moments.
Worked across marketing, product, analytics and technology teams to make the operating model repeatable.
Used frequency controls, campaign prioritisation and performance feedback to protect customer experience while increasing useful reach.
What should move if the strategy is working?
What changed?
Built and scaled Amazon Pay's push notification engine to a 5MM MAU customer base in six months.
Turned push from a campaign execution channel into a repeatable lifecycle marketing system across multiple customer use cases.
Principles, not playbooks.
The best CRM programme is not the one that sends the most messages. It is the one that makes the next message more useful.
Scale should come from decision rules and reusable systems, not campaign volume.