Test 080

Pricing/counting ambiguity is popping up after Sarah’s first budgetary wording. Discord — #eng-team Thread: Mercury pricing count / preview-only question Date: 2023-08-31 09:08 AM — Jake Quick pricing/counting question from the new Mercury budgetary wording. If an invited Evergreen user clicks in via magic link, looks around the preview/sample data, but never connects a real source or gets to a live sync, is that person part of the “monthly active developer” band for pricing, or not? Trying to make sure we don’t accidentally recreate seat logic by counting everyone who merely lands in the product. 09:12 AM — Anna Martinez I’d keep that separate. Preview/sample-only was deliberately non-activating in the external wave, and activation is still the corrected definition: real_source_connected or first_live_sync_completed within 7 days. If we let preview traffic do double duty as both “kind of active” and “kind of activated,” our reporting gets muddy fast. 09:14 AM — Jake Yep. I don’t want docs or dashboards to imply “opened preview once = active developer.” We also have internal Scaffold folks hitting the invite flow while testing org setup / retry paths. Those definitely shouldn’t roll into anything customer-facing. 09:17 AM — Anna Martinez Agreed on internal/test users staying out. Otherwise we’d be charging off our own dogfood and also polluting the early wave data. 09:21 AM — Sarah Kim I need a customer-safe sentence here because Evergreen may ask why the budgetary range is tied to monthly active developers instead of total seats in their directory. I can say “budget is based on actual monthly active developer usage in Mercury, not provisioned seats,” but I do not want to ad-lib what counts as active if the next question is “what about someone who only opened the preview?” 09:25 AM — Jake That’s exactly the edge case. Right now an invited person can successfully get into the bounded preview experience before anyone has connected a real source. That makes sense for product, but it leaves a counting gray area if someone reads “usage” too loosely. 09:29 AM — Devon Hayes The rule needs to stay forecastable. If this turns into a one-off exception list by customer, finance and budgeting conversations get messy immediately. Broadly: - pricing bands should map to monthly active developer usage, not directory size or purchased seats - internal Scaffold/test traffic should not count - preview/sample-only behavior should not get smuggled into activation reporting What I do not want is an Evergreen-specific carveout or a shadow seat count hiding underneath the usage model. 09:34 AM — Sarah Kim +1 on no Evergreen carveout. If they ask, I need to keep it budgetary and non-custom. I don’t want to imply a procurement packet, special enterprise policy, or roadmap trade in a one-line answer. 09:36 AM — Anna Martinez Also please don’t collapse “preview-only” into “active” just because we can see session events. We intentionally kept sample data preview-only and non-activating. Reporting-wise, that should remain a distinct bucket from actual activation. Otherwise every retention/activation chart gets re-litigated again. 09:41 AM — Jake Understood. My fear was that someone sees “Pilot includes up to 50 monthly active developers” and interprets that as “count every invited person who clicked once.” That gets us right back to seat-ish behavior, just with different words. 09:45 AM — Devon Hayes Right, and the model only works if the number is explainable without a long footnote. “Actual monthly active developer usage” is good. “Actual usage, except for these seven enterprise edge cases” is bad. Let’s not reopen the seat-versus-usage argument every time a broad directory exists. 09:49 AM — Sarah Kim For Evergreen-facing language, I’ll stay with budgetary guidance tied to actual monthly active developer usage and avoid promising how any future enterprise/security packaging would be counted. If they push past that, I’ll pause rather than improvise. 09:52 AM — Anna Martinez Thanks. And on the internal side, let’s keep preview/sample-only separate from the corrected activation definition in every doc/dashboard. Even if pricing uses an activity concept, activation still means real_source_connected or first_live_sync_completed within 7 days. 09:56 AM — Jake Makes sense. I’ll hold off on answering the eng docs question until we have one clean sentence everyone can reuse. Post a short channel note in #eng-team so this doesn’t stay buried in the thread. Clarify that Mercury pricing bands are based on monthly active developer usage, not purchased seats or directory size; Scaffold/internal test users don’t count; preview/sample-only activity stays separate from activation reporting; any Evergreen-facing answer stays budgetary and non-custom; and nobody should reopen the MAU-versus-seat debate or invent enterprise exceptions in customer emails.