[gonzaloebiz]

Part 1 of the library-side telemetry ask. Three lines of code and rather more comment.

observeRoot() already reads account_id, total_subscribers, account_name and email off the account root. pricing_plan_type is on that same response and was not read.

Verified against a live account rather than taken from the issue: pricing_plan_type is present on the
same response as the four fields observeRoot() already reads, and answered with one of the documented
values.

Choices worth stating

Kept as the string the API gave, not mapped to an enum. Three values are known in the field — monthly, forever_free, pay_as_you_go — but a fourth would collapse into whatever a default happened to be, and silently. Bounded at 32 characters like the other string fields here.

First-non-empty wins, matching account_id and the owner pair rather than total_subscribers, which overwrites. The billing arrangement is an attribute of the account a bucket is already attributed to, so it should not move under a report mid-process.

It is not the plan tier, and the docblock says so at length. Nothing on this response distinguishes Essentials from Standard from Premium. A reader who assumes otherwise would draw a conclusion the data cannot support, and that is exactly the kind of assumption a comment should stop rather than leave to be discovered.

Passive: no new call, no quota, nothing added to any request.

Verified

bucket plan_type   = 'monthly'
envelope full      = 'monthly'
envelope lean      = absent      <- below the lean cut, with the other identifying fields
account_id         = unchanged

tools/no-deprecated-calls.php: 64 files, 0 findings.

Key name

Emitted as pricing_plan_type, matching Mailchimp's own spelling on the response it is read from — the
same rule total_subscribers follows. Long form rather than abbreviated, because this is read once per
process rather than per call, so there is no saving to trade a translation step for.

[dipola]

The code is right and I have nothing to change in it.

observeRoot() was already reading four fields off that response and this is the fifth. First-non-empty matching owner_email immediately above it, rather than total_subscribers which overwrites, is the correct call: this is an attribute of the account, not a measurement of it, and it should not move under a report mid-process. The 32-character bound matches its neighbours. And the docblock spending most of its length ruling out the tier reading is the part I would have asked for if it were not already there — that is the misreading this field invites, and a comment is the only thing that stops it.

The key name

Use pricing_plan_type — Mailchimp's own spelling, unabbreviated.

The precedent on this lane is total_subscribers, which is literally the name Mailchimp uses on that same response, and the per-audience keys follow the same rule. The short spellings are reserved for the high-frequency per-beacon fields, where the saving is real. An account-root attribute read once per process belongs with the long-form group, and matching the upstream name means nobody has to hold a translation in their head.

The tag is not blocked on you

Nothing consumes either spelling yet. That side is ours and it has not been built — so the silent outcome you are describing is real, but it is ours to fix and not a reason to hold your tag.

Name it pricing_plan_type and tag whenever suits you. The value starts landing when we ship the consumer. The only outcome worth avoiding is a rename after a tag, and naming it now is exactly what prevents that.

One thing in the description, before this is tagged

Not the code — the pull request description.

The verification block prints a live account identifier, an address and a contact figure, and the closing section describes behaviour on our side of the wire. Neither belongs in a public repository. A description is editable, which several things here are not, so this is cheap to fix now and expensive later.

Could you take both out? Happy to keep the same shape — the choices you set out are worth having in public, it is only those two pieces that are not. I will send you the specifics separately rather than repeat them here.

[dipola]

Approved. pricing_plan_type at all three sites and the 32-character bound intact — this matches the wire exactly, and the receiver now has somewhere to put it.

The docblock ruling out the tier reading is the part that will still be earning its keep in a year.