Meta Best-Practice Setup

Last updated: June 30, 2026

1. Warum das Setup wichtig ist

Meta nutzt Datasets, Catalogs und Produktdaten, um Nutzerinteraktionen, Käufe und Produkte miteinander zu verknüpfen. Diese Informationen bilden die Grundlage für Attribution, Reporting, Kampagnenoptimierung und katalogbasierte Anzeigenformate.

Wenn das Setup nicht sauber konfiguriert ist, kann Meta Käufe, Produkte und Nutzerinteraktionen nicht mehr zuverlässig zuordnen. Dadurch entstehen häufig fehlerhafte Signale für den Algorithmus sowie ungenaue Performance-Daten.

Typische Folgen eines fehlerhaften Setups sind:

  • Überattribution von Käufen

  • doppelt gezählte Conversions

  • niedrige Catalog Match Rates

  • unvollständiges Reporting

  • schlechtere Performance von Catalog Ads

  • inkonsistente Kampagnenergebnisse

Deshalb empfehlen wir, Catalogs, Datasets und Produkt-IDs möglichst einfach und eindeutig zu strukturieren. Die folgenden Best Practices helfen dabei, typische Fehlerquellen zu vermeiden und eine saubere Datenbasis für Reporting und Kampagnenoptimierung sicherzustellen.


2. Dataset Best Practices

2.1 Nur eine Trackingquelle pro Dataset verwenden

Bevor weitere Einstellungen geprüft werden, sollte sichergestellt werden, dass das mit Mable verbundene Meta Dataset ausschließlich Daten von Mable erhält.

Sobald Mable als zentrale Trackingquelle für Meta eingesetzt wird, sollten andere Trackingquellen, die dieselben Events an dasselbe Dataset senden, deaktiviert werden.

Typische zusätzliche Trackingquellen sind beispielsweise:

  • Shopify Facebook & Instagram App

  • Meta Pixel über Google Tag Manager

  • Meta Pixel über Shopify Customer Events

  • Manuell implementierte Meta Pixel

  • Andere Server-Side-Tracking-Lösungen

  • Weitere Third-Party-Trackingtools

Werden dieselben Events von mehreren Quellen gleichzeitig an dasselbe Dataset gesendet, kann Meta dieselben Nutzerinteraktionen mehrfach erfassen.

Dadurch entstehen häufig:

  • Doppelt gezählte Käufe

  • Überhöhte Conversion-Werte

  • Fehlerhafte Attribution

  • Inkonsistente Reporting-Daten

  • Verfälschte Optimierungssignale

  • Schlechtere Algorithmusperformance, da dieser von besseren Ergebnissen ausgeht als tatsächlich erzielt werden

2.1.1 Wie kann geprüft werden, ob ein Dataset von Overtracking betroffen ist?

Es gibt verschiedene Möglichkeiten zu prüfen, ob zusätzliche Trackingquellen Daten an dasselbe Meta Dataset senden.

Möglichkeit 1: Vergleich mit der Mable Order Analysis

Eine einfache Möglichkeit besteht darin, die Anzahl der von Mable erfassten Bestellungen mit der Anzahl der Purchase Events im Meta Dataset zu vergleichen.

Dazu im Mable Dashboard:

Analytics → Order Analysis

Anschließend im Meta Events Manager:

Events Manager → Dataset auswählen → Overview → Purchase Event

Eine kleine Abweichung ist normal. Größere Unterschiede können jedoch darauf hindeuten, dass mehrere Trackingquellen dieselben Käufe an Meta senden.

 Wichtig:
Der Vergleich sollte immer für den gleichen Zeitraum erfolgen.

Möglichkeit 2: Vergleich mit dem Mable Event Control

Zusätzlich sollte geprüft werden, ob die im Meta Dataset sichtbaren Events mit den im Mable Event Control konfigurierten Events übereinstimmen.

Dazu:

  1. Mable Dashboard → Optimizations → Event Control → Meta

  2. Die dort konfigurierten Events notieren

  3. Anschließend im Meta Events Manager das entsprechende Dataset öffnen

  4. Unter Overview die eingehenden Events prüfen

Wenn über den Events Manager im Dataset Events sichtbar sind, die nicht im Mable Event Control konfiguriert wurden (z. B. Search), deutet dies häufig darauf hin, dass zusätzliche Trackingquellen Events an dasselbe Dataset senden.

Möglichkeit 3: Vergleich von Browser- und Server-Events

Im Meta Events Manager können außerdem die Browser- und Server-Events eines Events miteinander verglichen werden.

Wenn deutlich mehr Browser Events als Server Events erfasst werden, deutet dies häufig darauf hin, dass zusätzlich ein Frontend-Pixel aktiv ist und dieselben Events mehrfach an Meta sendet.

2.1.2 Was tun, wenn Overtracking festgestellt wird?

Wenn deutlich mehr Purchase Events im Dataset ankommen als tatsächliche Bestellungen vorhanden sind oder zusätzliche Trackingquellen identifiziert werden, sollte geprüft werden, welche Datenquellen mit dem Dataset verbunden sind.

Wenn beispielsweise weiterhin die Shopify Facebook & Instagram App Daten an denselben Datensatz sendet, kann dies durch das Deaktivieren des Datasharings behoben werden.

Die vollständige Schritt-für-Schritt-Anleitung zum Deaktivieren des Shopify Datasharings findet ihr hier :

https://scribehow.com/o/fl-pFDEPSpia9ZzF-8i-YA/viewer/How_To_Update_Facebook_And_Instagram_Channel_Settings__Nkd9OXyxToGOlYZWhnzQFw

2.2 Pro Ad Account möglichst nur ein aktives Dataset verwenden

Grundsätzlich empfehlen wir, innerhalb eines Meta Ad Accounts möglichst nur das Mable Dataset für Kampagnen zu verwenden.

Der Hauptgrund dafür ist die Doppelattribution, die entstehen kann, wenn mehrere verschiedene Datasets innerhalb desselben Ad Accounts für denselben Store verwendet werden.

Hintergrund:

Meta attribuiert Conversions pro Dataset.

Wenn mehrere verschiedene Datasets in einem Ad Account genutzt werden, die im gleichen Store eingebunden sind, erfassen diese dieselben Käufe.

Wenn zwei verschiedene Kampagnen – von denen eine auf ein Conversion Event aus Dataset 1 und die andere auf ein Conversion Event aus Dataset 2 optimiert – jeweils Touchpoints mit einem Nutzer hatten, bevor dieser kauft, kann derselbe Kauf beiden Kampagnen attribuiert werden.

Dadurch wird derselbe Kauf mehrfach im Werbekonto erfasst.

Dies führt häufig zu:

  • Doppelattribution von Käufen

  • Überhöhten Conversion-Zahlen

  • Überhöhten Conversion-Werten

  • Überhöhten ROAS-Werten

  • Verzerrten Kampagnenergebnissen

2.3 Wann mehrere Datasets sinnvoll sein können

In den meisten Fällen empfehlen wir, pro Store nur ein aktives Dataset für Kampagnen zu verwenden.
Es gibt jedoch Situationen, in denen mehrere Datasets sinnvoll sein können.

Unterschiedliche Stores

Wenn mehrere voneinander unabhängige Shops betrieben werden, kann der Einsatz mehrerer Datasets sinnvoll sein.

Ob hierfür tatsächlich mehrere Datasets benötigt werden oder ob ein gemeinsames Setup sinnvoller ist, hängt vom konkreten Anwendungsfall ab und sollte individuell bewertet werden.

Unterschiedliche Markets

Wenn Events bewusst nach Markets auf unterschiedliche Datasets aufgeteilt werden, beispielsweise:

  • Deutschland

  • Frankreich

  • USA

kann ebenfalls mit mehreren Datasets gearbeitet werden.

Dies macht jedoch nur dann Sinn, wenn pro Market ausreichend Datenvolumen vorhanden ist, damit der Algorithmus stabil lernen kann.

Meta A/B Tests

Eine weitere Ausnahme sind echte Meta A/B Tests.

Meta trennt hierbei die Zielgruppen bewusst voneinander, sodass Ergebnisse sauber miteinander verglichen werden können und keine Überschneidungen in der Attribution entstehen.

Damit aber ein A/B Test sauber ausgewertet werden kann, muss das Setup korrekt aufgesetzt werden, sodass die Ergebnisse eindeutig interpretierbar sind.

Wenn ein Kunde einen Meta A/B Test plant, empfehlen wir deshalb, vorab auf uns zuzukommen.
Dann können wir einen passenden A/B-Test-Guide bereitstellen und gemeinsam prüfen, ob der Test sauber aufgesetzt wurde.


3. Catalog & Product Matching Best Practices

3.1 Warum Catalogs für Meta wichtig sind

Catalogs ermöglichen Meta, Produkte mit Nutzerinteraktionen zu verknüpfen.

Dadurch werden Funktionen wie:

  • Advantage+ Catalog Ads

  • Produkt-Retargeting

  • Automatische Produktempfehlungen

erst möglich.

Damit dies funktioniert, muss Meta erkennen können, welches konkrete Produkt betrachtet, in den Warenkorb gelegt oder gekauft wurde.

Je einfacher und sauberer die Catalog-Struktur aufgebaut ist, desto zuverlässiger funktioniert dieses Matching.

3.2 Ein Catalog pro Dataset

Grundsätzlich empfehlen wir:

1 Catalog = 1 Dataset

Ein Catalog sollte möglichst nur mit einem Dataset verbunden sein.

Wenn mehrere Datasets an denselben Catalog angeschlossen werden, können die gleichen Käufe von beiden Datasets getrackt und dann mehrfach attribuiert werden

Dadurch entstehen häufig:

  • Überattribution in den Catalog Ads

  • Überhöhtes Reporting für Käufe, Conversion Value & ROAS der Catalog Ads im Ad Account

  • Schlechtere Ad Performance, weil der Algorithmus verwirrt wird

3.3 Ein Dataset pro Catalog

Ebenso empfehlen wir:

1 Dataset = 1 Catalog

Ein Dataset sollte möglichst nur mit einem Catalog verbunden sein.

Wenn ein Dataset gleichzeitig mit mehreren Catalogs verbunden wird, die die gleichen Produkte enthalten, wird jeder Kauf nur einem der verbundenen Catalogs zugeordnet.

Dadurch kann folgendes passieren

  • manche Käufe werden Catalog A zugeordnet

  • andere Käufe werden Catalog B zugeordnet

  • Catalog Match Rates sinken in einem oder beiden Catalogs

  • Catalog Ads performen schlechter

In der Praxis führt das häufig zu schlechteren Ergebnissen bei Catalog Ads.

3.4 Ausnahme: Mehrere Catalogs

Mehrere Catalogs können mit einem Dataset verbunden werden, wenn die Catalogs vollständig unterschiedliche Produkte enthalten und kein Produkt-Overlap besteht.

Beispiel 1:

  • Catalog A = Nahrungsergänzung

  • Catalog B = Haustierprodukte

Beispiel 2:

  • Catalog DE = Produkte im DE Store

  • Catalog US = Produkte im US Store

→ Voraussetzung: Die Produkte im DE Store haben vollständig andere Content IDs als die im US Store

In diesen Fällen kann ein Dataset mit mehreren Catalogs verbunden werden.

Sobald jedoch dieselben Produkte in mehreren Catalogs enthalten sind, empfehlen wir ausschließlich einen Catalog zu verwenden.

Grundsätzlich empfehlen wir insbesondere in Beispiel 1, lieber einen großen Catalog mit allen Produkten anzulegen und für gezielte Kampagnen lieber mit Product Sets innerhalb dieses Catalogs zu arbeiten, anstatt mehrere separate Catalogs anzulegen.

3.5 Product Matching & Catalog Match Rate

3.5.1 Warum Product Matching wichtig ist

Damit Meta Käufe einem Produkt im Catalog zuordnen kann, nutzt Meta sogenannte Content IDs.

Bei jedem Produkt-Event werden Produktinformationen an Meta übergeben, insbesondere bei:

  • ViewContent

  • AddToCart

  • Purchase

Meta gleicht anschließend die übermittelte Content ID mit den Produkten im Catalog ab.

Nur wenn beide IDs übereinstimmen, kann Meta das Produkt korrekt zuordnen.

Wie die Catalog Match Rate entsteht

Die Qualität dieses Abgleichs wird über die sogenannte Catalog Match Rate sichtbar.

Die Catalog Match Rate beschreibt, wie viele Produkt-Events erfolgreich einem Produkt im Catalog zugeordnet werden konnten.

Eine hohe Match Rate bedeutet:

  • korrekte Content IDs

  • funktionierendes Product Matching

  • saubere Catalog-Verknüpfung

…und führt zu guter Performance der Catalog Ads.

Eine niedrige Match Rate deutet häufig auf Probleme im Product Matching hin.

Typische Ursachen sind:

  • Unvollständiger Meta Catalog

  • falsche Content IDs

  • mehrere Catalogs mit Produkt-Overlap mit dem gleichen Dataset verbunden

  • inkonsistente Produktdaten

  • fehlerhafte Catalog-Verknüpfungen

Meta empfiehlt Catalog Match Rates von über 90 %.

Warum die Catalog Match Rate wichtig ist

Je besser das Product Matching funktioniert, desto besser kann Meta:

  • Produkte retargeten

  • Advantage+ Catalog Ads optimieren

  • Kaufwahrscheinlichkeiten berechnen

  • Produktempfehlungen generieren

Eine schlechte Match Rate bedeutet häufig, dass Meta Nutzerinteraktionen zwar erkennt, diese aber keinem konkreten Produkt zuordnen kann.

Dadurch stehen weniger verwertbare Signale für den Algorithmus zur Verfügung und katalogbasierte Kampagnen können schlechter performen.

3.5.2 Welche Produkt-IDs Shopify kennt

Shopify verwendet grundsätzlich drei verschiedene Produkt-Identifikatoren.

Product ID

Die Product ID wird von Shopify automatisch erstellt und existiert auf Produktebene.
Alle Varianten eines Produkts teilen sich dieselbe Product ID.

Product Variant ID

Die Product Variant ID wird ebenfalls von Shopify automatisch erstellt.
Jede einzelne Produktvariante erhält eine eigene Variant ID.
Auch Produkte ohne sichtbare Varianten besitzen intern immer eine Default Variant ID.

SKU

Die SKU wird manuell gepflegt.
Sie wird nicht automatisch von Shopify erzeugt und kann individuell von der Brand definiert werden.

3.5.3 Welche ID soll Mable an Meta senden?

Für das Product Matching ist nicht entscheidend, welche ID verwendet wird, sondern dass Mable dieselbe ID an Meta sendet, die im Catalog als Content ID hinterlegt ist.

Beispiel:

  • Catalog verwendet Product Variant IDs → Mable muss Product Variant IDs senden

  • Catalog verwendet SKUs → Mable muss SKUs senden

  • Catalog verwendet SKUs, Mable sendet Product IDs → Matching funktioniert nicht

Welche ID Mable an Meta sendet, kann unter folgendem Pfad konfiguriert werden:

Store Settings → Destination Connection → Meta → Manage Connection → Catalog

Dort kann ausgewählt werden, welche ID Mable an Meta senden soll:

  • Product ID

  • Product Variant ID

  • SKU

Die vollständige Schritt-für-Schritt-Anleitung zur Anpassung der Product Identifier findet ihr hier :

https://scribehow.com/o/fl-pFDEPSpia9ZzF-8i-YA/viewer/How_to_Connect_Your_Shopify_Catalog_to_Meta__IYeBj7IKSz-cwsD0hj6f6A?mode=edit

Wichtig:
Die in Mable ausgewählte ID muss immer mit der im Meta Catalog verwendeten Content ID übereinstimmen. Nur dann kann Meta Produkte korrekt zuordnen und eine hohe Catalog Match Rate erreichen.

3.5.4 Welche ID verwendet mein Catalog?

Bevor die Product Identifier in Mable konfiguriert werden, sollte zunächst geprüft werden, welche Content ID im bestehenden Meta Catalog verwendet wird.

Öffnet dazu im Meta Commerce Manager den entsprechenden Catalog, geht in den Bereich Products und öffnet ein beliebiges Produkt. In den Produktdetails findet ihr das Feld Content ID. Dieser Wert muss anschließend mit den IDs in Shopify verglichen werden, um den verwendeten ID-Typ zu bestimmen.

Dafür gibt es zwei Möglichkeiten:

Methode 1: Vergleich über die Shopify-URL

  • Entspricht die Content ID der Zahl hinter /products/, handelt es sich um eine Product ID.

  • Entspricht die Content ID der Zahl hinter /variants/, handelt es sich um eine Product Variant ID.

  • Entspricht die Content ID der SKU des Produkts, wird die SKU verwendet.

Methode 2: Vergleich über die Shopify-JSON (empfohlen)

Sucht das Produkt anhand der Content ID in Shopify, öffnet es und ergänzt .json am Ende der Produkt-URL. Im JSON kann anschließend nach der Content ID gesucht werden. Anhand des Feldes, in dem sie erscheint, lässt sich der verwendete ID-Typ eindeutig bestimmen:

  • product.id → Product ID

  • variants.id → Product Variant ID

  • sku → SKU

Sobald der verwendete ID-Typ bekannt ist, sollte dieser wie in Kapitel 3.5.3 beschrieben auch in Mable als Product Identifier ausgewählt werden.

Die vollständige Schritt-für-Schritt-Anleitung, um die Content ID im Meta Catalog zu prüfen und mit den IDs in Shopify abzugleichen, findet ihr hier :

https://scribehow.com/o/fl-pFDEPSpia9ZzF-8i-YA/viewer/How_to_Identify_the_Product_Identifier_Used_in_Your_Meta_Catalog__avpfkXe7RdyNSaibTWP0xg

3.5.5 Shopify-App vs. manuell erstellte Catalogs

Wenn der Catalog über die offizielle Meta-Shopify-App erstellt wurde, werden in den meisten Fällen Product Variant IDs verwendet.

In diesem Fall ist die Product Variant ID normalerweise die richtige Einstellung in Mable.

Anders sieht es aus, wenn der Catalog beispielsweise erstellt wurde über:

  • Channable

  • Feed Management Tools

  • CSV Uploads

  • manuelle Produktimporte

Dann sollte immer kontrolliert werden, welche IDs tatsächlich im Catalog hinterlegt sind.


4. Zusammenfassung der Best Practices

Tracking & Dataset-Struktur

  • Wenn Mable mit einem Dataset verbunden ist, sollten alle andere Trackingquellen für dieses Dataset deaktiviert werden.

  • Pro Meta Ad Account sollte nur das Mable Dataset für Kampagnen verwendet werden.

  • Ausnahmen können echte Meta A/B-Tests oder Setups sein, bei denen unterschiedliche Märkte bewusst in getrennte Datasets gesendet werden.

Catalog-Struktur

  • Ein Catalog sollte möglichst nur mit einem Dataset verbunden sein.

  • Ein Dataset sollte möglichst nur mit einem Catalog verbunden sein.

  • Mehrere Catalogs sollten nur verwendet werden, wenn diese vollständig unterschiedliche Produkte enthalten.

Product Matching

  • Die von Mable gesendete Produkt-ID muss mit der im Catalog verwendeten Content ID übereinstimmen.

  • Entscheidend ist nicht, welche ID verwendet wird, sondern dass Catalog und Tracking dieselbe ID nutzen.

  • Die verwendete Content ID sollte regelmäßig im Commerce Manager überprüft werden.

  • Die entsprechende Product Identifier Einstellung in Mable sollte dazu passend konfiguriert werden.

Catalog Match Rate

  • Eine hohe Catalog Match Rate ist Voraussetzung für funktionierende Catalog Ads

  • Meta empfiehlt Match Rates von über 90 %.

  • Eine niedrige Match Rate deutet häufig auf Probleme bei Content IDs, Catalog-Struktur oder Catalog-Verknüpfungen hin.

Ziel des Setups

Ein sauberes Dataset-, Catalog- und Product-Matching-Setup sorgt für:

  • korrekte Attribution

  • zuverlässiges Reporting

  • stabile Optimierungssignale

  • funktionierende Catalog Ads

  • bessere Performance von Catalog-Kampagnen

Dadurch erhält Meta eine möglichst saubere Datenbasis für Kampagnenoptimierung und Ausspielung.