Skip to main content
Click “Copy Page” to copy this use case as markdown.

Problem

Users frequently buy name-brand products without realizing equivalent store-brand alternatives exist at the same retailer for significantly less. Store brands are often 25-55% cheaper for comparable items, but most users default to name brands out of habit. Without visibility into what was purchased at the SKU level, there is no practical way to surface these savings at the right moment.

Solution

Retrieve SKU-level transaction data from the Sync Transactions endpoint. Compare the products users purchase against a catalog of comparable products at the same merchant. When a cheaper alternative exists in the same category, surface it as a proactive savings tip.
iPhone lock screen showing a push notification: Grocery savings opportunity found — You can save $2.50 each time you buy ketchup with a different brand at Walmart
This gives users a concrete, actionable savings insight tied to their real purchases, without requiring any change to their checkout behavior.

Flow

Implementation

1

Sync transaction data

When a user switches their card at a merchant or they simply link their merchant account w/o switching their card, Knot begins collecting transaction data for that account. Listen for the NEW_TRANSACTIONS_AVAILABLE webhook event, then call Sync Transactions to sync SKU-level transactions on a daily basis.Key fieldsOnly include transactions with order_status of COMPLETED, DELIVERED, PICKED_UP, SHIPPED, BILLED, or ORDERED. Filter out CANCELLED, REFUNDED, and FAILED.
2

Build and maintain a product catalog

As transaction data accumulates across your users, maintain a per-merchant product catalog. Knot can provide a products[].category and products[].subcategory on each product, so no custom categorization logic is required. Use subcategory for matching where available - it groups products at the right level of specificity (e.g., “creamy peanut butter” rather than just “condiments”).
Cross-user data compounds the value: as more users shop at a merchant, the catalog grows to cover more categories and refine price signals for each product.
3

Detect alternatives

On each incoming transaction (or on a daily job), check whether any product in the order has a cheaper alternative in the same category at the same merchant.
Configuration decisions for your team:Trigger timing options:
  • Real-time (preferred): Run the check on each incoming transaction. Best for high-savings items where the impact is immediate and the user is likely to remember the purchase.
  • Weekly digest: Aggregate all matched alternatives from the week and present a cumulative “you could have saved $X” summary. Less disruptive for small per-item amounts.
  • Hybrid: Real-time for savings above $2 per item; weekly digest for smaller gaps.
4

Surface the savings suggestion

When an alternative is identified, notify the user with the product name, what they paid, the store-brand alternative, and the potential savings.Push notification:
Save $2.50 on ketchup next time. You can save $2.50 each time you buy ketchup with a different brand at Walmart.
Deeplink the user to a screen displaying more details about the savings opportunity, including a direct link to the alternative product, so they can check it out more deeply.

Expansion Path

  • Broader merchant coverage: Extend the catalog to additional retailers with established store brands. Each new merchant multiplies the addressable product categories and addressable users.
  • Personalized suggestions: Use a user’s purchase history to prioritize alternatives they are most likely to try. Users who already buy some store-brand products in a category are significantly more likely to switch in adjacent categories. Surface those first.
  • Weekly savings digest: Aggregate all suggested swaps from the past week and send a single in-app card showing total potential savings. This keeps the feature visible without generating a notification per purchase.