Bing Ads-integration

Ved at forbinde dit katalog til Microsoft Merchant Center vises dine produkter for kunder på Microsofts søgenetværk – en pulje af søgeefterspørgsel, der ikke fuldt ud overlapper med Googles. For de fleste annoncører betyder det en gradvis rækkevidde og ofte en lavere pris pr. klik end Google Shopping, uden at man skal kunne opbygge et andet katalog fra ingenting.

Microsofts Content API-guide viser Shopping-kampagner og produktannoncer som understøttet på tværs af en bred vifte af markeder – fra USA, Canada og Storbritannien til mindre markeder som Malta, Mauritius, Cypern og Fiji – med et yderligere sæt lande tilgængelige for pilotkunder. Denne bredde betyder, at et enkelt, velstruktureret feed kan udvide en Shopping-tilstedeværelse til markeder, du måske ikke har prioriteret på Google.

Fordi Microsofts produktskema bevidst er bygget til at være interoperabelt med Googles, driver de fleste af de samme produktdata – titel, pris, billeder, GTIN, brand, MPN – der kræves til et Google Merchant Center-feed også dine Microsoft Merchant Center-lister, hvilket holder den trinvise opsætningsindsats relativt lav.

Microsofts Content API-dokumentation er usædvanligt åbenhjertig omkring, hvor dens skema låner fra Googles – og hvor den stille og roligt afviger. En række felter i Product-objektet findes udelukkende "for Google-kompatibilitet": Microsofts API accepterer additionalImageLinks, adwordsGrouping, adwordsLabels, destinationsog taxes, men dens egen dokumentation angiver tydeligt, at Microsoft Merchant Center slet ikke bruger disse felter. Hvis du genbruger et Google-formateret feed, passerer disse felter simpelthen uskadeligt igennem i stedet for at gøre noget for Microsofts side.

Microsoft dokumenterer også en funktion, som Google Shopping ikke har i samme form: Shoppingkampagner for brandsI denne kooperativmodel uploader en producent en produktliste, der kun indeholder Brand, GTINog MPN, forbinder den til en detailpartners Microsoft Merchant Center-butik, og begge parter kan derefter byde på den delte liste over matchede produkter – og dermed dele omkostningerne ved klik. Microsofts dokumentation bemærker, at dette i øjeblikket er begrænset til USA og Storbritannien og er under åben betaversion for pilotkunder.

Endnu en praktisk afvigelse: Microsoft afviser eksplicit produkter for voksne ("produkter for voksne understøttes ikke og vil blive afvist"), og de opretholder deres egen identifikatorvalideringslogik (se afsnittet om obligatoriske attributter nedenfor), der kører uafhængigt af den validering, dit feed allerede har bestået for Google.

Microsoft Merchant Center accepterer dit katalog på to hovedmåder i henhold til den officielle dokumentation:

1. En flad feed-fil uploadet til din butik eller dit katalog, indsendt regelmæssigt via FTP/SFTP.
2. Indholds-API'en — en RESTful, JSON-baseret API dokumenteret på content.api.bingads.microsoft.com/shopping/v9.1/bmc/ — til at indsætte, opdatere, hente og slette individuelle produkter eller behandle dem i bulk via /products/batch slutpunkt.

Content API'ens batch-slutpunkt dokumenterer konkrete begrænsninger, der er værd at planlægge omkring: en enkelt batch-anmodning kan indeholde op til 12,000 elementer, men den samlede anmodningstekst må ikke overstige 4 MB, så Microsofts egen vejledning er, at du typisk kan have 2,000-6,000 ukomprimerede tilbud pr. batch (op til de fulde 12,000, hvis du gzip-komprimerer nyttelasten med Content-Encoding: gzip header). Listeanmodninger pagineres med maksimalt 250 produkter pr. kald ved hjælp af max-results og start-token.

Produkterne findes i et Microsoft Merchant Center butik, og en butik kan eventuelt indeholde flere kataloger (specificeret med bmc-catalog-id parameter ved indsættelse). Hvert tilbud, du indsender, skal have en udløbshorisont: Microsofts dokumentation bekræfter, at medmindre du angiver en eksplicit expirationDate, et tilbud udløber automatisk 30 dage efter, at det blev skrevet til butikken.

Microsofts Content API-reference er eksplicit omkring, hvilke felter der er obligatoriske for at indsætte et tilbud, og hvilke der bliver obligatoriske betinget. I henhold til den officielle produktressourcedokumentation:

Feedance opbygger Microsoft Merchant Center-feedet direkte fra de produktdata, du allerede administrerer i din butik eller PIM – ingen manuelle regnearkseksporter. Kortlægningsprogrammet tildeler dine kildefelter til Microsofts skema, inklusive composite-ID-felterne (channel, contentLanguage, targetCountry, offerId) som Microsoft låser efter første indsendelse, så det er vigtigt at få dem med det samme.

1. Forbind din butik eller datakilde (e-handelsplatform, PIM eller eksisterende produkteksport) med Feedance.
2. Knyt dine felter til Microsofts obligatoriske og betingede attributter — Feedance markerer manglende identifikatorer og anvender identifierExists: false automatisk når mærke, GTIN eller MPN reelt ikke er tilgængelige, så du ikke indsamler undgåelige advarsler.
3. Generer feedet i den struktur, som Microsofts Content API og Store Intake forventer, og lever det via planlagt feedupload eller direkte API-indsendelse til dit Microsoft Merchant Center-butiks-ID.
4. Feedance overvåger de resulterende produktstatusser — Godkendt, Advarsel, Afvist, Afventer og Udløber — så du kan se og rette itemLevelIssues uden at logge ind på Microsoft Advertising-webappen for hver kontrol.

Da din eksisterende Google Merchant Center-kortlægning allerede dækker de fleste af de samme attributter, som Microsoft kræver, er det typisk et spørgsmål om at gennemgå attributterne og ikke om at genopbygge den ved at forbinde en anden destination via Feedance.

Microsofts egen dokumentation fastsætter en hård bagstop: medmindre du eksplicit fastsætter en expirationDate, udløber ethvert tilbud automatisk 30 dage efter, at det sidst blev skrevet til butikken - hvorefter det ikke længere er berettiget til at blive vist. Blot at indsende produktet igen (selv uden at ændre felter) nulstiller 30-dages uret, men kun hvis du ikke manuelt har angivet en eksplicit udløbsdato selv.

I praksis er den 30-dages udløbsdato et loft, ikke et mål. Da pris og tilgængelighed skal stemme overens med det, der står på din live produktside, validerer Microsoft eksplicit, at feedet price matcher produktets webside — ethvert katalog med regelmæssige prisændringer, udsolgte varer eller kampagner bør opdateres langt oftere end én gang om måneden. En kadenc på mindst dagligt holder tilgængelighed og priser nøjagtige og undgår det tavse hul mellem, hvornår et produkt er udsolgt, og hvornår dit feed indhenter det forsømte.

Microsofts Content API returnerer konkrete, dokumenterede statuskoder for problematiske tilbud i stedet for vage afvisninger. To virkelige eksempler direkte fra Microsofts egen reference til produkttilbudsstatusser:

1. GtinPlusBrandRequiredWarn — "Mangler en eller flere identifikatorer - Brand og GTIN eller Brand og MPN er påkrævet." Dette er en advarsel, ikke en direkte afvisning: Microsofts serverbarhedsfelt markerer det som "Upåvirket", hvilket betyder, at tilbuddet stadig vises, men du bør rette det - enten angive de rigtige identifikatorer eller angive identifierExists til false hvis ingen findes.
2. EVRejectedErr parret med en specifik årsagskode, f.eks. EV_39 ("Varemærkeindhold") — dette er en hård afvisning; Microsofts dokumentation viser tilbuddets status feltet er indstillet til "Afvist" og servability indstillet til "Afvist", hvilket betyder, at produktet ikke vises, før det markerede indhold er rettet.

Ud over individuelle problemer med varer bekræfter Microsofts dokumentation, at hvert tilbud efter at have bestået en grundlæggende validering gennemgår yderligere "offlinevalideringer og -gennemgange, såsom redaktionelle gennemgange, der kan tage op til 36 timer", før det er berettiget til at blive vist – så et nyligt indsendt eller nyligt opdateret tilbud, der har status som "afventer" i en dag, er forventet adfærd, ikke en fejl. En oversigtsvisning på butiksniveau (kan nås via ProductStatuses-ressourcen) rapporterer tællinger på tværs af approved, disapproved, expiringog pending, som er den hurtigste måde at se katalogets tilstand med et hurtigt overblik.

1. Angiv alle tre identifikatorer, når de findes. Microsofts dokumentation er eksplicit, at hvis en producent har tildelt et GTIN, brand eller MPN, skal du inkludere det – udeladelse af en kendt identifikator producerer GtinPlusBrandRequiredWarn advarsel, selvom tilbuddet stadig gælder. Hvis ingen af ​​dem reelt gælder, skal du indstille identifierExists til false i stedet for at lade felterne være tomme.
2. Gruppevarianter med itemGroupId. For et produkt, der sælges i flere farver, størrelser eller mønstre, anbefaler Microsofts dokumentation at oprette ét tilbud pr. variant og linke dem til en delt itemGroupId i stedet for at forsøge at proppe alle muligheder ind i ét tilbud.
3. Brug customLabel0-customLabel4 til kampagnesegmentering. Disse fem felter findes specifikt, så du kan filtrere og byde på delmængder af dit katalog i Microsoft Shopping-kampagner.
4. Hold titler og beskrivelser fri for reklamer. Begge felter må eksplicit "ikke indeholde salgsfremmende tekst", og begge gennemgår redaktionel gennemgang – salgssprog indbygget i titlen risikerer at blive misbilliget i stedet for at generere klik.
5. Spor udløb proaktivt. Fordi tilbud udløber lydløst 30 dage efter deres sidste opdatering, medmindre du angiver dine egne expirationDateFeeds til langsomt omsættelige kataloger skal stadig opdateres regelmæssigt, selvom ingen af ​​de underliggende produktdata er ændret.
6. Udfyld shipping for tyske annoncer. Microsofts dokumentation markerer forsendelse, forsendelsesetiket og forsendelsesvægt efter behov. targetCountry af DE — en regel, der er let at overse, hvis dit primære marked er et andet sted.

Er "Bing Ads" stadig et rigtigt produktnavn? Nej — Microsoft omdøbte Bing Ads til Microsoft Advertising i 2019. "Bing Merchant Center" er nu Microsoft Merchant Center. Den underliggende platform og Shopping-kampagnemekanikken er uændret; kun navnet er.

Kan jeg genbruge mit Google Merchant Center-feed til Microsoft? Stort set ja. Microsofts produktskema afspejler mange Google Merchant Center-feltnavne og adskillige Google-orienterede felter (destinations, taxes, adwordsGrouping, adwordsLabels, additionalImageLinks) accepteres udelukkende af kompatibilitetsgrunde, selvom Microsofts dokumentation bekræfter, at de ikke bruges. Du bør stadig gennemgå Microsoft-specifikke obligatoriske felter som f.eks. channel og betingede regler som Tysklands skibsfartskrav.

Er et GTIN obligatorisk for alle produkter? Kun hvis producenten har tildelt en. Microsofts dokumentation kræver gtin, brandog mpn når de eksisterer; hvis de virkelig ikke gør det, sæt identifierExists til false i stedet for at lade dem stå tomme.

Hvad sker der, hvis jeg stopper med at opdatere mit feed? I henhold til Microsofts dokumentation udløber hvert tilbud automatisk 30 dage efter den seneste opdatering (medmindre du har angivet dine egne expirationDate), og et udløbet tilbud ophører med at være berettiget til visning.

Hvor lang tid tager gennemgangen, efter jeg har indsendt eller opdateret et produkt? Microsofts dokumentation angiver, at tilbud efter grundlæggende validering gennemgår yderligere offline-gennemgange, herunder redaktionel gennemgang, der "kan tage op til 36 timer", før tilbuddet er berettiget til at blive vist.

Kan jeg indsende mit feed via FTP i stedet for en API? Ja — Microsoft Merchant Center understøtter tilbagevendende indsendelse af feedfiler ud over den JSON-baserede Content API, så teams uden udviklingsressourcer stadig kan automatisere leveringen.