Cloud Marketplace Buyer Data and How You May Use It

Cloud marketplace buyer data is what AWS, Microsoft and Google Cloud tell a seller about the customers who buy through their marketplaces: an account identifier, a company and its location, and on Microsoft the people who bought. AWS and Microsoft also limit what you may do with it, in the terms you accepted to sell.

---

Acme’s marketing team is planning a fourth-quarter campaign and asks RevOps for everyone who bought through a cloud marketplace this year. RevOps can build the list: company names and email domains from AWS’s data feeds, purchaser email addresses from Microsoft’s fulfillment API, company names from Google’s insights report. Whether marketing may email it is a different question, and the data can’t answer it.

The answer sits in the terms Acme accepted to sell. AWS’s Seller Terms and Microsoft’s Publisher Agreement both limit what a seller may do with buyer information the marketplace provides. This guide sets out what each cloud sends, quotes each limit in full, and ends with a checklist. It quotes rather than interprets, and it isn’t legal advice: take hard cases to counsel. Matching these identifiers to CRM accounts is covered in connecting your CRM to cloud marketplace data.

What is cloud marketplace buyer data?

Cloud marketplace buyer data is the information a cloud provider gives a seller about a customer who transacted through its marketplace. It comes in three layers: identifiers that key every record, a company and its location, and sometimes the people who bought. Of the feeds and APIs in this guide, only Microsoft’s carry a buyer’s name or email address.

Two things sit outside it: a listing lead, which starts as a request for contact rather than a transaction, and what a buyer types into your own registration page, which you collected rather than the cloud sent. Both come up below.

What does each cloud send about a buyer?

Each cloud sends an identifier, a company and a location; only Microsoft sends people, and the feeds, schedules and use limits differ.

	AWS Marketplace	Microsoft Marketplace	Google Cloud Marketplace
Buyer identifier	AWS account ID, plus a LicenseArn at SaaS sign-up	tenantId and objectId for the purchaser and the beneficiary; CustomerId in the Customers report	Cloud Billing account_id; an external_account_id for every customer
Company and location	company_name, email_domain and the full address on file	Company name and address “provided by the customer”	company, domain (the website field in Google’s CRM) and location
People	None in the feeds; AWS suggests collecting email addresses on your registration page	emailId for the purchaser and the beneficiary; name and email in the Customers report, with consent; purchase leads	None; personal accounts show n/a
Feed or API	Address and account data feeds; an email to you when a customer accepts an offer	SaaS fulfillment API; Customers report in Partner Center; leads	Customer insights report
Cadence	Feeds refreshed every 24 hours	API on demand; Customers report within 48 hours of acquisition	Daily, a day behind; monthly
Use limit	Seller Terms 3(f): support and delivery, or internal sales metrics, unless agreed in writing with the subscriber or otherwise permitted by law	Publisher Agreement 7(b)(iii): transactional purposes or a customer inquiry; consent for any other use, including marketing	None on the Google pages cited here; check your agreement with Google
Reseller case	CPPO: AWS emails you the customer’s company name and AWS account ID; the reseller won’t disclose its Subscriber Information except as the AWS Marketplace Service Terms expressly permit	MPO: under Addendum B §1(k), Microsoft may share contact information it obtained for the partner; CSP: the purchaser can differ from the beneficiary	Resold: company and domain are the reseller’s

What does AWS Marketplace tell you about a buyer?

An AWS account ID when the buyer signs up, then a company name, an email domain and an address in the data feeds. Three sources carry it:

• The sign-up token. For a SaaS product, AWS sends the buyer to your registration page with a token that you redeem through ResolveCustomer “for your customer’s AWS account ID, LicenseArn, and product code.” No name or email comes with it. AWS’s advice for that page: “We recommend collecting your customer’s email addresses if you plan to contact them through email for usage notifications.”
• The data feeds. The address data feed “provides contact information for all the accounts you interact with: your own, any channel partners you work with, buyers, payers, and all taxed accounts.” Its company_name is “The company name on file for this account,” and its email_domain is “The domain for the email address on file for this account”: a domain, not an address. Street, city, state or region, postal code and country complete the row. The feed “is refreshed every 24 hours,” “Address data is immutable,” and a transaction whose address isn’t already in the feed adds a new entry. The account data feed links each account to its mailing and tax addresses and, for non-US accounts, adds the legal company name, “the name used on tax invoices.”
• The acceptance email. When a customer accepts an offer, AWS emails the ISV the “Customer company name, Customer AWS account ID,” the agreement ID and dates, and the purchase amount. It goes to the email address of your AWS account’s root user, and AWS says agreement emails are available for select product types.

AWS’s buyer guide describes the sharing from the buyer’s side: contact information for “customer training and technical support,” for “software activation, configuration, and customization of content,” and so sellers can “Compensate their sales teams internally,” plus “certain information” to help sellers “evaluate the effectiveness of their marketing campaigns.” Otherwise, AWS says, what it shares “is not personally identifiable” unless the buyer permits it or AWS believes the law requires it. The guide describes what AWS may share; the Seller Terms govern what you may do with it.

What may you do with AWS Subscriber Information?

Use it to support and deliver your product or to compute internal sales metrics, unless you and the subscriber agree otherwise in writing or the law permits another use. The Service Terms for AWS Marketplace Sellers, last updated September 30, 2026, define Subscriber Information broadly: “any data or information to which you have access in connection with AWS Marketplace or any Offering, including data or information concerning any Subscriber, any Transaction, or any use of services offered by AWS with your Offerings.” A Subscriber is “any customer(s) subscribed to your Offering(s).” Section 3(f) sets the limit:

f. Subscriber Information. Except as agreed to in writing between you and the respective Subscriber, or otherwise permitted by law, you may only use Subscriber Information for: (a) providing support for and facilitating the delivery of your Offerings; or (b) computation of your internal sales metrics. This Section does not apply to information that you acquire from Subscribers outside of your use of AWS Marketplace, even if that information is identical to Subscriber Information. You may not use Subscriber Information for any other purpose, unless otherwise agreed in writing between you and the respective Subscriber.

The clause sets out four things:

• Two purposes: support for and delivery of your offerings, and internal sales metrics. Marketing isn’t named.
• Two exceptions: a written agreement “between you and the respective Subscriber,” and a use “otherwise permitted by law.” Its last sentence names only the written agreement.
• One carve-out: information you acquire from subscribers “outside of your use of AWS Marketplace,” even when it is identical. The Seller Terms don’t define that phrase, and AWS doesn’t say whether a registration page that buyers reach from AWS Marketplace falls inside or outside it. Ask counsel rather than assume.
• A life beyond your listing: Section 11 says Section 3 survives “any removal or disablement under these Seller Terms and the termination or expiration of your AWS Agreement.”

What does Microsoft send about a buyer, and what may you do with it?

Microsoft sends names and email addresses as well as tenant IDs, and Section 7(b)(iii) of its Publisher Agreement limits that contact information to transactional purposes and answering customer inquiries. Three channels carry them:

• The SaaS fulfillment API. The Resolve call returns the subscription with a purchaser and a beneficiary, each with an emailId, objectId, tenantId and puid. Microsoft notes that the purchaser’s details “could be different from beneficiary information for reseller (CSP) purchase.”
• The Customers report in Partner Center analytics. It holds first and last name, email, company name and address “provided by the customer,” which can differ from the customer’s Azure subscription. “Customer personal information is only available if the customer provides consent,” only owner-role users see it, a protected customer’s details are masked, and reporting trails acquisition by up to 48 hours.
• Purchase leads. Microsoft shares “leads information with you about customers who complete the product purchase,” in fields that can include name, email, phone, company and title.

In the Customers report, PromotionalCustomers “lets you know if the customer proactively opted in for promotional contact from publishers,” and Microsoft says that because it isn’t yet presenting that option to customers, the column reads “No” across the board.

Microsoft’s limit sits in Section 7(b)(iii) of the Publisher Agreement, whose July 2026 update took effect on July 1, 2026:

(iii) Contacting Customers. Microsoft may share Customer contact information with you, which may include Personal Data. The Customer contact information and Personal Data we provide you must be used solely for transactional purposes or to respond to a Customer inquiry about your Offers that are available in the Microsoft Marketplace and in accordance with Data Protection Law. You may not use the Customer contact details we provide to direct Customers to purchase your Offer on competing marketplaces. You are responsible for obtaining Customer’s consent for any other use, including for marketing purposes, of Customer contact information or Customer Personal Data obtained from Microsoft, and Microsoft will not be responsible or liable for such other use.

That is two purposes, one prohibition, and consent for any other use, “including for marketing purposes,” which is yours to obtain.

What does Google Cloud send about a buyer?

A company name, a domain and a location in the customer insights report, keyed to the Cloud Billing account, and nothing that names a person. Google provides “a daily and monthly customer insights report, which includes information about who your customers are, and how they are using your software.” Each daily report is generated the day after the date it covers, based on Pacific Time, and the monthly report on the first day of the following month.

• company is “The customer’s company name.”
• domain is “The value of the website field for this account in Google’s CRM system”: Google’s record of the company’s website, not the domain of anyone’s email address.
• account_id is the Cloud Billing account. external_account_id, an Insights ID generated for that account, “is present for all customers, even those with personal accounts.”
• Country, state or province, city and postal code give the location.

A buyer who sets up the Cloud Billing account as personal rather than business is the exception: Google excludes identifying information, and “For those accounts, you see n/a in the columns.” The report’s one email column, quote_creator, holds “the email address of the offer creator” for a private offer, not a buyer’s. At sign-up, Google’s token carries a procurement account ID and an obfuscated user reference, which you can pass as a login_hint to start “an OAuth 2.0 consent flow” with the buyer; the token itself carries no email address.

Google says less about use. Its Marketplace Terms of Service, which buyers accept, say: “Customer acknowledges and agrees that Google may share certain account and usage information related to its purchases and use of Vendor Products with the applicable Vendor.” None of the Google pages cited here sets a use limit for vendors, so read the agreement you accepted with Google to sell on its marketplace before using the report for anything beyond delivery and reporting.

Who is the buyer when a partner resells the deal?

A resold deal still has an end customer, but each cloud shows you something different: AWS names the customer and the partner, Microsoft may share what it obtained for the partner, and Google shows the reseller.

AWS channel partner private offers (CPPO). When a customer accepts a channel partner private offer, AWS emails the ISV the “Customer company name, Customer AWS account ID,” the channel partner’s name and AWS account ID, and the wholesale price. What the partner may pass on is set by Section 4 of the AWS Marketplace Resale Addendum, which the Seller Terms incorporate when you authorize resellers:

Unless otherwise agreed by the applicable Subscriber, as between Authorized Reseller and Listing Owner, Subscribers are purchasing Authorized Resale Products only from Authorized Reseller and such resales by Authorized Reseller do not create a Subscriber relationship with Listing Owner. Authorized Reseller will not, except as expressly permitted under the AWS Marketplace Service Terms, disclose to Listing Owner any Subscriber Information arising from Authorized Reseller’s resale of Authorized Resale Products to Subscribers or allow Listing Owner to use any such Subscriber Information.

Microsoft multiparty private offers (MPO) and CSP. Addendum B §1(k) of the Publisher Agreement covers MPO:

(k) Customer Information. Microsoft may share Customer contact information obtained for Authorized Partners with ISVs, as if ISV were a Publisher under Section 7(b)(ii) of the Agreement Terms and Conditions, and subject to the restrictions of that Section. Any sharing of Customer information or Personal Data between ISV and Authorized Partner is subject to Section 7 of the Agreement Terms and Conditions.

Section 1(f) of the same addendum adds that MPO resales “do not create a billing relationship between ISV and Customer.” In a purchase through a Cloud Solution Provider (CSP), the subscription’s purchaser can differ from its beneficiary, and the Customers report names the CSP or reseller in ProviderName and ProviderEmail.

Google Cloud resold transactions. For “transactions that involve vendors reselling Cloud Marketplace products,” company is “the name of the vendor reselling the products to the customer,” and domain is “the domain linked to the account of the reselling vendor.”

How the three resale mechanisms compare is covered in CPPO vs MPO: reselling on the cloud marketplaces.

Is a listing lead the same as buyer data?

No. A listing lead is a request for contact, while buyer data comes from a transaction; keep the two apart, even where one channel carries both. Microsoft’s leads channel does. It describes leads as “customers interested in or deploying your offers” and generates one in two places:

• When a customer selects Contact me and “consents to sharing their information.” Microsoft calls this an initial interest lead.
• When a customer completes a purchase, in Microsoft Marketplace or with Create in the Azure portal.

Each lead’s LeadSource field tells them apart: PLT for a Contact me request, INS when a customer acquires your product in Microsoft Marketplace, Create for a purchase in the Azure portal, and DNC, “do not contact,” for a request made to a partner cross-listed on your page, which Microsoft passes on as a notification only. Section 7(b)(iii) doesn’t treat leads separately from other customer contact information Microsoft shares.

What may your team do with marketplace buyer data?

Deliver, support and measure; before any marketing, get the buyer’s written agreement on AWS or consent on Microsoft, and check your agreement with Google. The checklist restates the clauses above; it’s a starting point for counsel, not a substitute.

Allowed within the clauses

• Deliver, activate and support the product: 3(f)(a) on AWS, “transactional purposes” on Microsoft.
• Answer a customer’s inquiry about your offers, a purpose 7(b)(iii) names.
• Compute internal sales metrics: 3(f)(b) on AWS, whose buyer guide also names compensating sales teams.

Only with the buyer’s written agreement or consent

• Marketing email, nurture sequences, newsletters and ad-audience uploads: on AWS, a written agreement with that subscriber, unless the use is “otherwise permitted by law”; on Microsoft, the customer’s consent, which you must obtain. Microsoft’s own opt-in column reads “No” for everyone today.
• Any other use the clauses don’t name.

Never

• Use contact details Microsoft provides to direct customers to buy your offer on competing marketplaces.

Before anyone uses the data

• Record each record’s source. 3(f) stops at information acquired “outside of your use of AWS Marketplace,” and a source field lets counsel draw that line once, not per campaign. This is our practice, not an AWS rule.
• Filter AWS’s address and account feeds to buyers: they also carry your own account and your channel partners.
• Check a resold deal against AWS’s Resale Addendum §4 or Microsoft’s Addendum B §1(k).
• Sort Microsoft leads by LeadSource, and treat a DNC lead as a notification only.
• On Google Cloud, read your agreement with Google before going beyond delivery and reporting.

Where does marketplace buyer data go in Fours?

Fours syncs AWS’s buyer information from the data feeds and uses Google’s insights report to enrich its buyer records. This is Fours behaviour, as Fours’ documentation describes it:

• AWS Marketplace. Fours’ AWS integration includes the Marketplace Data Feeds Service (MDFS), which its setup guide highly recommends, and the KMS access it needs “is for MDFS integration, which syncs revenue data and buyer information (company name, address, and email domain)”: the same three things AWS’s address feed carries.
• Google Cloud Marketplace. Fours syncs the insights report as “Customer and company metadata used to enrich buyer records,” and “resolves each charge to the matching Fours buyer, product, and entitlement where possible.” Orders sold through a reseller “are tagged as Resold with the reseller’s details; direct orders are tagged Direct.”

The clauses above still govern what your team does with that data. If the same feeds also land in your data warehouse, exporting marketplace data to your warehouse covers how they arrive and how to keep their history.

Frequently asked questions

Can marketing email customers who bought through AWS Marketplace?

Not with AWS Subscriber Information, absent an exception. AWS’s Seller Terms §3(f) limit it to support and delivery or internal sales metrics, except under a written agreement with the subscriber or as otherwise permitted by law. Information acquired outside your use of AWS Marketplace isn’t covered.

Does AWS give sellers the buyer’s email address?

Not in its data feeds. The address feed’s email_domain column holds “The domain for the email address on file,” not the address itself. AWS recommends collecting customers’ email addresses on your registration page if you plan to email them usage notifications.

What may you do with Microsoft Marketplace customer contact information?

Use it for transactional purposes or to answer a customer’s inquiry about your offers, in line with data protection law. Section 7(b)(iii) makes you responsible for the customer’s consent to any other use, including marketing, and bars using it to steer customers to buy on competing marketplaces.

Why does a Google Cloud insights report show a reseller’s name?

Because the transaction was resold. For resold transactions, Google fills company and domain with the reselling vendor’s name and domain. Personal accounts show n/a instead, and domain is the website field in Google’s CRM, not an email domain.

Does a CPPO hide the end customer from the ISV?

No. When a customer accepts a channel partner private offer, AWS emails the ISV the customer company name and AWS account ID. The Resale Addendum bars the reseller from disclosing the Subscriber Information from its resale to you, except as the AWS Marketplace Service Terms expressly permit.

What buyer data does Fours sync?

Fours’ AWS integration syncs buyer information (company name, address and email domain) through the Marketplace Data Feeds Service. On Google Cloud, Fours uses the insights report to enrich buyer records and tags orders sold through a reseller as Resold, with the reseller’s details.

Takeaways

• AWS sends an account ID, a company name, an email domain and an address; Microsoft sends tenant IDs, names and email addresses; Google sends a company, a domain and a location, or n/a for personal accounts.
• AWS’s 3(f) limits Subscriber Information to support, delivery and internal sales metrics unless the subscriber agrees otherwise in writing or the law permits more, and it outlasts your listing.
• Microsoft’s 7(b)(iii) allows transactional use and answering inquiries; marketing needs the customer’s consent.
• On resold deals, AWS still emails you the customer’s company name and account ID, Microsoft may share what it obtained for an MPO partner, and Google shows the reseller.
• Keep listing leads apart from transaction data, and record each buyer record’s source.

Fours syncs AWS’s buyer information from the data feeds and enriches its buyer records from Google’s insights report, with resold Google orders tagged by reseller. See how it fits your revenue reporting in Fours’ cloud marketplace reporting and revenue analytics.