What the platform is actually used for

Traffic is not adoption

The single most important thing on this page: the busiest parts of the platform are not the most-adopted parts, and neither ranking alone should drive a roadmap.

Who these merchants are

Before any feature number means anything, the base has to be split correctly. Demo accounts are excluded throughout, and the platform's own platform_type turns out to disagree with what merchants actually do.

As labelled: merchants.platform_type

As measured: what they actually did in 30 days

The non-integrated loyalty group is, as expected, effectively empty: one merchant recording visits with no POS source while also sending campaigns. It is a real configuration, not a segment worth building for.

The self-registration pipeline

New merchant creation has more than quadrupled since December, and it is almost entirely messaging-first.

August is a partial month and already the largest on record. The composition changed sharply from June onward: demo accounts went from ~1 a month to 29 in August, and 94% of new merchants are created as messaging-first.

What merchants actually turn on

Distinct billing-active, non-demo merchants against a denominator of 652, measured over 30 days.

Adoption clusters tightly: once a merchant is genuinely live, they tend to run campaigns, audiences and automations together in the 40–45% band. There is very little partial adoption between "transacting" and "using the product" — merchants are mostly on one side or the other.

The loyalty funnel, end to end

Thirty days of activity, from grant issued to reward redeemed.

Automation: three winners and a long tail

23 auto-campaign types are enabled somewhere in production. Three account for most adoption; most of the rest are used by fewer than 30 merchants each.

Three types have zero enabled instances anywhere: Unredeemed Reward Reminder, Expiring Reward Reminder, and Join by Referral. They exist in the type registry and in the code, and no merchant runs them.

MessageTemplates: a second sending vertical

Alongside campaigns and auto-campaigns there is a third, largely separate messaging path. It behaves much like API-triggered auto-campaigns but carries none of the stashboard features, and the merchants using it are mostly not dispensaries.

The volume is concentrated in suspended accounts

For its current users it is the only channel

The ten merchants sending via templates in the last 30 days sent zero campaigns over the same twelve months. This is not a secondary path they also use — it is their entire messaging surface. Bring It On! sent 30,019 template messages to 16,682 members; GTI Delivery 15,448 to 3,864; Yayz 9,660 to 2,797.

Scale of the supporting tables: 8,654,467 send logs, 3,011,259 status rows, 1,414,187 error rows, 83,264 template states. Templates themselves are 27,719 rows across 745 merchants, so definition is far more widespread than use — 230 active non-demo merchants have at least one template defined, but only 10 sent anything in 30 days.

Messaging channels

Email carries twice the volume of SMS, but SMS reaches twice as many merchants.

Channel combinations, by merchant count: SMS-only 207 · SMS+email 46 · email-only 76 · all three 31 · push-only 24 · SMS+push 27 · email+push 11.

Where the traffic actually goes

34.9 million requests over seven days, classified by who is calling.

The five busiest individual endpoints are all POS: member lookup (7.5M), member list (4.1M), rewards list (3.1M), the mobile stashboard (3.1M) and offers list (2.5M).

The POS surface is long-tailed

No integration exceeds 17% of active merchants. There is no dominant partner, and that is a strategic fact rather than a technical one.

Where configuration and code meet

Several findings in this report are not engineering defects and not account oversights on their own — they occur where a per-account setting has no system-level check behind it. Both halves have to move for them to stop recurring.

The pattern

Three independent flags govern whether a merchant accrues loyalty points: merchant.loyalty, member.allowed_loyalty and merchant_location.loyalty_points. A fourth field, merchant.platform_type, describes what the account was sold. Nothing reconciles them.

def loyalty_enabled?                       # visit.rb:413
  if merchant&.loyalty && member&.allowed_loyalty
    return false if merchant_location && !merchant_location.loyalty_points
    true
  ...

platform_type is absent from that method. Its only enforcement is a permissions check on dashboard access (user.rb:116). The result is that the commercial description of an account and its runtime behaviour can drift apart indefinitely, and nothing surfaces the drift.

What would close it

What this says about the roadmap

Method & caveats

Adoption figures come from the production Postgres replica, read-only, over 30 days, counting distinct merchants where current_status_cache = 'active' and demo_account IS NOT TRUE (652). Traffic figures come from New Relic over 7 days, filtered to appName = 'springBIG' to exclude staging and beta. Endpoint classification is by URL prefix and is mine, not a system-defined taxonomy.

• Seeded rewards are excluded from the reward figure. Merchants are provisioned with a default "Sample Reward" at signup. Counting it would report 99.0% adoption; excluding it gives 64.6%. The test was name plus creation-time proximity to the merchant record, corroborated by redemption activity (7 redemptions across 2,488 seeded rows in 180 days).
• Merchant segments were excluded from the adoption ranking. All merchants have at least one, across 1.55M rows — that is default provisioning, not a feature choice, and reporting it as 100% adoption would be misleading.
• Messaging volumes are denormalized campaign counters (campaigns.sms_sent and siblings), i.e. what the application recorded at send time. Delivery-confirmed counts from the log tables would read lower. The log tables were not queried: sms_logs is 1,410 GB and push_logs has no date index, so any date-bounded query forces a sequential scan on a shared replica.
• Reward-grant counts use a primary-key range rather than a date predicate, because reward_grants (586 GB) has no index on created_at. The boundary was binary-searched and verified accurate to within seconds. The counts are real count(*) results.
• Native-app adoption is org-level, not merchant-level. app_settings keys on merchant_organization_id, so active merchants sit under an organization with a native app — which is not the same as 594 merchants each having their own.
• Cloudflare cannot answer this question and was not used. No POS or partner traffic transits the edge; its top hosts are SMS landing domains and S3. Feature usage lives in Rails and Postgres.
• Visit counts use transaction_date (business date); redemption counts use created_at (insert time). Slight window skew between the two.