cross-merchant-identity

Cross-Merchant Identity — The Real Product

The RPG gamification is the acquisition hook. The actual value proposition is a shared customer identity graph across independent merchants — cooperative intelligence that only chains and big-box retailers currently have.

One customer shops at a local coffee shop, a bookstore, a bike repair place. Today those three businesses know nothing about each other’s customers. OutsideRPG/Guild is the connective tissue. The RPG framing gives customers a reason to opt into a unified identity voluntarily — they want one profile because it’s their character.

Why the game mechanic solves the hard problem

Customer identity unification normally requires forced account creation or cross-site tracking. Here it’s opt-in and motivated: players maintain one character because it’s theirs. That consent mechanism is the moat.

Schema: player is the central entity

The player is not a loyalty record — it’s a cross-merchant identity.

-- The player is the product
players (id, email_hash, phone_hash, display_name, level, total_xp, created_at)
 
-- Identity resolution layer: one player, many merchant relationships
player_merchant_links (player_id, guild_id, square_customer_id, first_seen_at, last_seen_at)

player_merchant_links is how you unify Square’s per-location customer IDs under one player account. Square gives different customer IDs per location — you resolve them through the player’s platform login.

Supporting tables

guilds (id, square_location_id, name, tier, collective_xp, created_at)
transactions (id, square_transaction_id, player_id, guild_id, amount_cents, xp_earned, created_at)
xp_events (id, player_id, source_type, source_id, xp_amount, metadata_jsonb, created_at)
achievements (id, player_id, achievement_type, unlocked_at)

xp_events is the append-only event log. Transactions are one source of XP; others include streaks, guild milestones, bonus events. Keep total_xp denormalized on the player row and update it transactionally with each XP event — avoids recalculating from the event log on every read.

Analytics that become possible

Once you have cross-merchant player data:

• Cross-merchant purchase frequency and timing patterns
• Category affinity across verticals (books + coffee + fitness = behavioral cluster)
• Churn signal: a player stops visiting one guild but stays active elsewhere — the quiet guild gets an alert
• Cohort insights: “customers who shop at businesses like yours also tend to shop at X category”
• Anonymized aggregate data across the network: “businesses in your category with similar customer overlap see 30% higher retention when they run joint promotions”

The anonymized aggregate layer is what big retail runs internally and independents have zero access to. That’s the analytics product.

Privacy model — this is the moat

Merchant A should see: “this customer also shops at 2 other local businesses.”
Merchant A should NOT see: which businesses, unless those businesses opt into mutual visibility.

Get the privacy model wrong and you’re dead on arrival. Get it right and it’s the reason merchants trust the network and stay.

Scale reality check

At 100 shops, a realistic transaction volume is ~100k transactions/day (~1–2 writes/second). Postgres handles this without breaking a sweat. ClickHouse and sharding are irrelevant at this scale.

The real engineering complexity is:

• Square webhook idempotency — webhooks get retried, arrive out of order, occasionally duplicate. Unique constraint on square_transaction_id handles it.
• Multi-shop identity resolution — one human, multiple Square customer IDs across locations. Decided at signup: one player per human across all guilds.
• Game balance math — XP curves, level thresholds, guild tier calculations. Separate into a pure function layer, not embedded in SQL.
• Leaderboards — first query to feel slow at scale. Materialized views or a Redis sorted set when needed. Not yet.

Relevance

This is the core OutsideRPG network value prop. The single-store experience (dungeon.club) proves the game mechanics. The multi-merchant network is what makes the platform defensible and commercially interesting. See also: outsiderpg-platform-vision, guild-multitenancy, ecosystem-architecture.