Interacted people entitlement

What it does

Interacted people is the meter Customer Insights - Journeys is priced on. It counts the Dataverse rows you have actually sent something to in the last 12 months — not the size of your database, and not the number of people in your segments.

Key facts

An interacted person is any entity engaged by an outbound interaction: a contact, a lead, a Customer Insights - Data profile, or a custom table row. The table it lives in doesn't matter; being marketed to does.
Each entity is counted once no matter how many messages it receives. Ten emails to one contact is one interacted person.
The count is a rolling 12-month window. Once an entity hasn't received or engaged an interaction for 12 months, it drops out and stops consuming quota. Consumption is otherwise cumulative across the licence period and survives a renewal.
Records that sit in the database and are never marketed to don't count at all. A tenant with two million contacts and 40,000 marketed to needs entitlement for the 40,000.
The meter is tenant-level. Usage is summed across every Dataverse environment on the tenant — production, sandbox, developer and trial alike. Microsoft's stated reasoning is that the storage and processing cost is the same whatever the environment type is called.
Interacted people is a completely separate meter from unified people, which is the Customer Insights - Data meter counting merged, deduplicated profiles. Buying one does not top up the other, and you can buy add-on packs of each independently.
Add-on capacity is sold as Interacted People T1–T3 packs. Tenants still on the legacy Marketing standalone licence who can't buy the old active contacts add-ons can buy these instead.
Your monthly interaction allowance is derived from this number, not bought separately — see the interaction quota doc.
Read usage in-app at Settings > Quota limits (older builds: Settings > Advanced settings > Other settings > Quota limits). The page shows the tenant-level entitlement, the usage on the environment you're in, and a separate "Other orgs in your tenant" line for everything else.
"Active contacts" is the old name for the same idea under the legacy Marketing SKU. Expect to see both terms in the same conversation.

When to use / skip

Every Journeys project has to size this, so the question isn't whether but how. The sizing input is not the contact count from the CRM, which is what clients always offer first. It's the number of distinct people you expect to send anything to across a rolling year, across all environments, including the ones the test team uses.

Where consultants go wrong is treating it as a database licence. A client with a large dormant contact base and a small active marketing programme needs far less than they fear. A client with a modest database who does a broad annual customer survey plus monthly newsletters may need more than they think, because a single broad send in one month pulls twelve months of counted entitlement behind it.

Configuration decisions

Whether marketing runs against contacts and leads directly, or against Customer Insights - Data profiles. All three count the same way, but the decision drives which records end up marketed to and therefore counted.
Whether test and UAT sends go to real records in a sandbox or to a small ring-fenced set of seed records. Every sandbox send consumes tenant entitlement.
How suppression is handled. Records excluded before send never become interacted people; records that receive a message and then unsubscribe already have.
Whether to buy for the annual peak or buy the base and add packs mid-year when the number moves.
Which team owns the quota page and how often somebody looks at it — monthly at minimum during the first year.
For clients running Customer Insights - Data as well, whether the unified people meter needs sizing at the same time or can be deferred.

Gotchas

Sandbox and dev environments consume the same tenant pool as production. A load test that emails 200,000 seeded records burns real entitlement, and it doesn't decay for twelve months.
The 12-month window means a single large one-off send has a long tail. Sending to a bought list once is not a one-month cost.
Entitlement shown in-app can look higher than what was bought. The usual causes are self-service trials sitting on the tenant, or old standalone licences still active alongside a new base licence. Both inflate the figure and both go away later.
Trial licences created by self-service sign-up never get removed from the tenant record, so the Power Platform admin centre listing tends to accumulate entries that mean nothing.
The interacted people count is not the same as the number of Dataverse rows you're storing. Dataverse capacity is a separate meter with a separate bill, tracked in the Power Platform admin centre under Licensing > Capacity add-ons.
Nothing in the in-app quota page tells you which records are consuming the quota. If the number is higher than expected, you're reconstructing it from journey and send history, not from a report.

Consultant notes

Ask for the client's peak marketing month and size from that, then say out loud that you've done so. It preempts the "why are we paying for capacity we don't use in February" conversation at renewal.
Get sandbox sending discipline agreed in writing before the first test cycle: a seed list, a small one, and a rule that nobody points a sandbox journey at a production-sized segment.
Tell the client the meter decays. Clients assume interacted people accumulate forever and panic-buy capacity that a rolling window would have released.
If they're moving from the legacy Marketing standalone licence, be explicit that active contacts and interacted people are the same meter under a different name, and that add-on packs on the new SKU work for them too.
The definitive entitlement wording is in the Dynamics 365 Licensing Guide PDF, not on Learn. Quote the guide when the client's procurement team asks for chapter and verse.

Worth another look if Microsoft changes the 12-month decay rule or renames the meter again.