“Bing Ads”是微软在2019年更名为“Microsoft Advertising”的产品目录工具的旧名称。许多广告商仍然称之为“Bing Merchant Center”的产品目录工具，如今已正式更名为“Microsoft Merchant Center (MMC)”。如果您的团队、代理机构或旧电子表格中仍然提到“Bing Ads”，那么它指的仍然是同一个平台，只是名称有所更改。
微软购物广告系列的运作方式与谷歌购物广告系列类似：您无需手动编写单个产品广告。相反，您只需将结构化的产品 Feed（包含标题、价格、图片和标识符的目录）上传到 Microsoft Merchant Center 商店，微软的投放引擎就会在 Microsoft 搜索网络上的搜索与产品属性匹配时，自动从该目录中生成并投放产品广告。根据微软自身的 Content API 文档，Feed 可以通过 Microsoft Advertising Web 应用进行管理，也可以通过 FTP/SFTP 提交，或者通过基于 REST 的 Content API 以编程方式推送。 https://content.api.bingads.microsoft.com/shopping/v9.1/bmc/.
在系统底层，您提交的每个产品都会通过一个由四个字段组成的复合 ID 进行识别—— channel, contentLanguage, targetCountry和 offerId —微软的文档明确指出，一旦产品被添加到商店，这四个字段中的任何一个都不能更改，因为这样做实际上会创建一个重复的产品。
将您的产品目录连接到 Microsoft Merchant Center，即可将您的产品展示在 Microsoft 搜索网络上的购物者面前——该搜索网络的用户群体与 Google 的搜索用户群体并不完全重叠。对于大多数广告主而言，这意味着更大的覆盖范围，而且每次点击成本通常低于 Google Shopping，无需从零开始构建第二个产品目录。
微软的内容 API 指南列出了支持在众多市场投放的购物广告系列和产品广告，涵盖美国、加拿大、英国等大国，以及马耳他、毛里求斯、塞浦路斯、斐济等较小的市场，此外，试点客户还可以在更多国家/地区体验。如此广泛的覆盖范围意味着，一个结构完善的单一信息流即可将购物广告拓展到您可能并未优先考虑的 Google 市场。
由于微软的产品架构是特意设计成与谷歌的产品架构互操作的，因此谷歌商家中心信息流所需的大部分相同产品数据（标题、价格、图片、GTIN、品牌、MPN）也适用于微软商家中心列表，这使得增量设置工作量相对较低。
微软的内容 API 文档异常坦诚地说明了其架构哪些地方借鉴了谷歌的架构，以及哪些地方悄然有所不同。产品对象中的一些字段纯粹是为了“与谷歌兼容”而存在的：微软的 API 将接受 additionalImageLinks, adwordsGrouping, adwordsLabels, destinations和 taxes但其自身文档明确指出，Microsoft Merchant Center 根本不使用这些字段。如果您重复使用 Google 格式的 Feed，这些字段会直接传递过去，不会对 Microsoft 端造成任何影响。
微软还以相同的形式记录了谷歌购物所不具备的一项功能： 品牌购物营销活动在这种合作模式下，制造商上传的产品列表仅包含…… Brand, GTIN和 MPN它将网站与零售合作伙伴的 Microsoft Merchant Center 商店连接起来，双方可以对共享的匹配产品列表进行竞价，从而分摊点击费用。微软的文档指出，这项功能目前仅限于美国和英国，并且正在面向试点客户进行公开测试。
还有一个实际的区别：微软明确拒绝成人产品（“不支持成人产品，将会被拒绝”），并且它维护着自己的标识符验证逻辑（见下文“必需属性”部分），该逻辑独立于你的信息流已经通过谷歌验证的任何验证而运行。
根据微软官方文档，Microsoft Merchant Center 接受您的商品目录主要有两种方式：
content.api.bingads.microsoft.com/shopping/v9.1/bmc/ — 用于插入、更新、检索和删除单个产品，或通过以下方式批量处理它们： /products/batch 端点。内容 API 的批量端点文档中明确规定了一些值得注意的具体限制：单个批量请求最多可以包含 12,000 个项目，但请求体总大小不能超过 4 MB，因此微软的建议是，通常每个批量请求可以包含 2,000 到 6,000 个未压缩的 offer（如果使用 gzip 压缩有效负载，则可以包含全部 12,000 个）。 Content-Encoding: gzip （标头）。列表请求使用分页，每次调用最多显示 250 个产品。 max-results 和 start-token.
产品存放在 Microsoft Merchant Center 中 商店一个商店可以选择性地包含多个 目录 （用 bmc-catalog-id 插入参数）。您提交的每个报价都需要一个有效期：微软的文档证实，除非您明确设置有效期，否则不会出现这种情况。 expirationDate优惠信息在发送给商店后 30 天自动失效。
微软的内容 API 参考文档明确规定了插入优惠信息时哪些字段是必填项，哪些字段会在特定条件下变为必填项。根据官方产品资源文档：
| 属性 | 需要？ | 注释（根据微软的文档） |
|---|---|---|
offerId | 是 | 用户自定义，在产品目录中唯一，最多 50 个字符。用于构建产品 ID——产品添加后无法更改。 |
title | 是 | 最多 150 个字符，允许使用任何 Unicode 字符。不得包含推广性文字；需经过编辑审核。 |
link | 是 | 产品页面的 URL，最多 2,000 个字符，必须与商店的域名匹配，并且不能是重定向。 |
imageLink | 是 | URL 最长 1,000 个字符；建议图片尺寸为 200x200 像素；文件大小不得超过 3.9 MB；需经过编辑审核。 |
price | 是 | 必须与产品页面上显示的价格一致；有效范围为 0.01 至 10,000,000.00（合约/分期付款手机和平板电脑有 0 美元的例外情况，需提供相关证明）。 |
availability | 是 | 其中一个 in stock, out of stock 或 preorder. 默认为 in stock. |
condition | 是 | 其中一个 new, refurbished 或 used. 默认为 new. |
channel | 是 | Online or Local. 复合产品 ID 的一部分；创建后无法更改。 |
contentLanguage | 是 | 这是微软支持的语言列表中的两位字母 ISO 639-1 代码，也是复合产品 ID 的一部分。 |
targetCountry | 是 | 两位字母的 ISO 3166 国家/地区代码；必须与产品目录中的市场相符。也是复合产品 ID 的一部分。 |
brand, gtin, mpn | 有条件要求 | 如果制造商指定了“插入时必需”，则必须勾选。如果您没有全部三个，则必须进行设置。 identifierExists 至 false — 否则，微软会接受该提议，但会发出警告。 |
shipping, shippingLabel, shippingWeight | 有条件要求 | 微软的文档特别指出，在以下情况下，这三者都是必需的。 targetCountry 是 DE（德国）；其他情况可选。 |
sizes | 有条件要求 | 面向法国、德国、英国或美国的服装及配饰产品需要此项。 |
Feedance 直接从您在商店或 PIM 中已管理的产品数据构建 Microsoft Merchant Center 数据源，无需手动导出电子表格。映射引擎会将您的源字段分配给 Microsoft 的架构，包括复合 ID 字段（channel, contentLanguage, targetCountry, offerId）微软会在首次提交后锁定，所以一开始就确保它们正确非常重要。
identifierExists: false 当品牌、GTIN 或 MPN 确实不可用时，会自动发出警告，这样您就不会收到不必要的警告。itemLevelIssues 无需每次检查都登录 Microsoft Advertising 网络应用程序。由于您现有的 Google Merchant Center 映射已经涵盖了 Microsoft 要求的大部分相同属性，因此通过 Feedance 连接第二个目标通常只是属性审查的问题，而不是重建的问题。
微软自己的文档设置了一个硬性限制：除非你明确设置，否则 expirationDate所有优惠信息都会在最后一次提交到商店后 30 天自动过期——届时该优惠将不再有效。只需重新提交产品（即使不更改任何字段）即可重置 30 天的期限，但前提是您没有手动设置明确的过期日期。
实际上，这 30 天的有效期只是一个上限，而不是目标。因为价格和库存信息必须与你的产品页面上的信息一致——微软会明确验证信息流是否正确。 price 与产品网页保持一致——任何价格会定期变动、缺货或促销的产品目录，其更新频率都应远高于每月一次。至少每天更新一次，可以确保库存和价格信息的准确性，避免产品售罄后信息更新滞后造成的空白期。
微软的内容 API 会针对问题报价返回具体、有文档记录的状态代码，而不是模糊的拒绝。以下两个示例均来自微软自身的产品报价状态参考文档：
GtinPlusBrandRequiredWarn — “缺少一个或多个标识符 - 必须提供品牌和 GTIN 或品牌和 MPN。” 这是 警告这并非直接拒绝：微软的服务性字段将其标记为“未受影响”，这意味着该服务仍然有效，但您应该修复它——要么提供真实的标识符，要么进行设置。 identifierExists 至 false 如果没有。EVRejectedErr 与特定原因代码配对，例如 EV_39 （“商标内容”）——这一点明确表示不予批准；微软的文档显示该提议…… status 字段设置为“不批准” servability 设置为“不予批准”，这意味着在标记的内容得到纠正之前，该产品将无法使用。除了个别商品的问题之外，微软的文档也证实，每项优惠在通过基本验证后，都会经过额外的“线下验证和审核，例如编辑审核，这可能需要长达 36 小时”，才能正式上线——因此，新提交或新更新的优惠状态停留一天属于正常现象，并非错误。商店级别的汇总视图（可通过 ProductStatuses 资源访问）会显示各项优惠的统计数据。 approved, disapproved, expiring和 pending这是快速查看目录健康状况的最佳方法。
GtinPlusBrandRequiredWarn 即使优惠仍然有效，也请发出警告。如果没有真正适用的优惠，请设置 identifierExists 至 false 而不是将字段留空。itemGroupId. 对于以多种颜色、尺寸或图案销售的产品，微软的文档建议为每个变体创建一个报价，并将它们与一个共享的报价链接起来。 itemGroupId 而不是试图把所有选项都塞进一个报价里。customLabel0–customLabel4 用于广告系列细分。 这五个字段的存在是为了方便您在 Microsoft Shopping 广告系列中筛选和竞价您的商品目录子集。expirationDate即使底层产品数据没有任何变化，缓慢更新的目录的数据源仍然需要刷新。shipping 适用于德国列表。 微软的文档特别指出，运输信息、运输标签和运输重量是特定情况下必需的。 targetCountry DE 的规则——如果你的主要市场在其他地方，这条规则很容易被忽略。“Bing Ads”现在还是一个真实的产品名称吗？不是——微软在2019年将Bing Ads更名为Microsoft Advertising。“Bing Merchant Center”现在也叫Microsoft Merchant Center。底层平台和购物广告系列机制没有改变，只有名称变了。
我可以将我的 Google Merchant Center Feed 用于 Microsoft 吗？ 基本上是这样。微软的产品架构与许多谷歌商家中心字段名称以及一些谷歌相关的字段名称类似（destinations, taxes, adwordsGrouping, adwordsLabels, additionalImageLinks即使微软的文档确认它不使用某些字段，但为了兼容性，仍然接受这些字段。您仍然需要查看微软特有的必填字段，例如： channel 以及像德国的运输要求这样的附加条件。
每个产品都必须有GTIN吗？ 只有在制造商指定的情况下才需要。微软的文档要求 gtin, brand和 mpn 如果它们存在，则设置；如果它们确实不存在，则设置 identifierExists 至 false 而不是留空。
如果我停止更新动态会发生什么？ 根据微软的文档，每项优惠都会在最后一次更新后 30 天自动过期（除非您自行设置了过期时间）。 expirationDate），并且过期的优惠不再符合服务条件。
提交或更新产品后，审核需要多长时间？微软的文档指出，经过基本验证后，优惠活动还会经过额外的线下审核，包括编辑审核，审核“最多可能需要 36 小时”，之后优惠活动才能正式上线。
我可以通过 FTP 而不是 API 提交我的信息源吗？可以——除了基于 JSON 的内容 API 之外，Microsoft Merchant Center 还支持定期提交信息源文件，因此即使没有开发资源的团队也能实现自动化交付。