Podwójne zamówienia Shopify w CRM. Jak wykryć zawyżoną sprzedaż i błędne dane o rentowności reklam?

Sklep Shopify zarejestrował 500 zamówień, ale system CRM pokazuje 530 transakcji? Raport sprzedaży wygląda lepiej niż rzeczywiste wyniki, a dane o przychodach nie zgadzają się z Google Analytics 4? Przyczyną mogą być zduplikowane rekordy tworzone podczas synchronizacji sklepu z zewnętrznym systemem CRM lub ERP. Problem występuje szczególnie w integracjach wykorzystujących webhooki Shopify, które przekazują informacje o zamówieniach i klientach niemal jednocześnie. Jeżeli aplikacja nie potrafi prawidłowo rozpoznawać istniejących transakcji, jedno zamówienie może zostać zapisane w CRM więcej niż raz.

Konsekwencje mogą wykraczać poza samą bazę klientów. Jeśli zewnętrzny system wykorzystuje zdublowane zamówienia do raportowania sprzedaży, obliczania wartości klientów lub przesyłania konwersji do Google Ads, przedsiębiorca może otrzymywać nieprawidłowe informacje o wynikach biznesowych. Zawyżone przychody, błędnie obliczony ROAS i niepoprawne dane o liczbie pozyskanych klientów mogą prowadzić do zwiększania budżetów kampanii, które w rzeczywistości nie przynoszą oczekiwanego zysku. Dlatego analiza danych sprzedażowych powinna obejmować nie tylko statystyki reklamowe, lecz także kontrolę spójności informacji przekazywanych pomiędzy systemami.

Shopify i Microsoft Dynamics CRM tworzą podwójne rekordy — rzeczywisty przypadek z października 2026 roku

30 października 2026 roku w oficjalnej społeczności Shopify pojawiła się dyskusja zatytułowana „How to Prevent Duplicate CRM Records When Multiple Shopify Webhooks Trigger Simultaneously?”. Autor opisał problem z własną integracją sklepu Shopify i Microsoft Dynamics CRM, przygotowaną w języku PHP. Aplikacja wykorzystuje webhooki do przekazywania informacji o tworzeniu i aktualizowaniu zamówień oraz klientów.

Po złożeniu zamówienia kilka powiadomień uruchamia się niemal jednocześnie. Jedno dotyczy nowej transakcji, inne utworzenia lub aktualizacji klienta. Ponieważ procesy działają równolegle, CRM w niektórych przypadkach zapisuje podwójne rekordy klientów i zamówień. Autor zaznaczył, że jego konfiguracja CRM nie posiada skutecznego mechanizmu automatycznego wykrywania duplikatów. Poszukuje więc sposobu na zagwarantowanie, że każda transakcja będzie przetwarzana tylko raz.

W odpowiedziach programiści wskazali trzy rozwiązania: unikalne identyfikatory rekordów wymuszane przez bazę danych, kolejki przetwarzania webhooków oraz operacje typu upsert, które aktualizują istniejący rekord albo tworzą nowy, jeśli nie został wcześniej zapisany. W przypadku Microsoft Dynamics 365 opartego na Dataverse zasugerowano wykorzystanie kluczy alternatywnych, identyfikujących zamówienie za pomocą identyfikatora sklepu i identyfikatora transakcji Shopify.

Nie potwierdzono, że sam Shopify tworzy podwójne zamówienia w swoim panelu administracyjnym. Zgłoszony problem dotyczy sposobu przetwarzania zdarzeń przez zewnętrzną integrację i zapisywania ich w CRM. Nie wiadomo również, czy duplikaty z opisanego przypadku zostały przekazane do systemów reklamowych. Jest to możliwy skutek wymagający niezależnego sprawdzenia, a nie potwierdzona konsekwencja konkretnego zgłoszenia.

Dlaczego webhooki Shopify mogą powodować podwójne zamówienia i klientów?

Webhook to automatyczne powiadomienie wysyłane przez Shopify, gdy w sklepie wystąpi określone zdarzenie. Integracja może otrzymywać informacje na przykład o utworzeniu zamówienia (orders/create), aktualizacji zamówienia (orders/updated), utworzeniu klienta (customers/create) albo zmianie jego danych (customers/update). Dzięki temu zewnętrzny system może na bieżąco aktualizować swoją bazę bez konieczności ciągłego pobierania wszystkich zamówień przez API.

Problem pojawia się wtedy, gdy kilka powiązanych powiadomień jest przetwarzanych równocześnie. Wyobraźmy sobie, że klient po raz pierwszy składa zamówienie w Shopify. System wysyła powiadomienie o nowym kliencie oraz osobne powiadomienie o zamówieniu. Dwa niezależne procesy PHP rozpoczynają w tym samym momencie sprawdzanie, czy klient istnieje już w Microsoft Dynamics.

Pierwszy proces wyszukuje klienta i nie znajduje jego rekordu. Drugi proces wykonuje identyczne wyszukiwanie, zanim pierwszy zdąży zapisać dane. Oba uznają więc, że klient jest nowy, a następnie tworzą dwa niezależne rekordy CRM. Podobna sytuacja może wystąpić przy obsłudze zamówień, jeśli różne webhooki uruchamiają tę samą procedurę tworzenia transakcji.

Taki problem nazywany jest race condition, czyli wyścigiem procesów. Błąd nie musi występować przy każdym zamówieniu. Może pojawiać się sporadycznie, szczególnie przy większym ruchu, dłuższym czasie odpowiedzi CRM lub chwilowym obciążeniu serwera. To sprawia, że jest trudny do wykrycia podczas zwykłych testów integracji.

Shopify może ponownie dostarczyć ten sam webhook

Drugim źródłem powtarzających się operacji jest mechanizm ponawiania dostarczenia powiadomień. Shopify wymaga, aby serwer odbierający webhooki szybko potwierdzał ich przyjęcie odpowiednim kodem HTTP z grupy 2xx. Jeśli połączenie się nie powiedzie, serwer nie odpowie w wymaganym czasie albo zwróci błąd, Shopify może ponowić wysłanie powiadomienia.

Zgodnie z dokumentacją Shopify system może wykonać do ośmiu ponownych prób w okresie około czterech godzin. Jeżeli pierwsze powiadomienie zostało już przetworzone, ale odpowiedź nie dotarła do Shopify, kolejne dostarczenie może ponownie uruchomić tę samą operację. Bez odpowiednich zabezpieczeń aplikacja może więc utworzyć drugi rekord tego samego zamówienia.

Nie jest to błąd Shopify. Mechanizm ponawiania zwiększa niezawodność dostarczania informacji, ale wymaga, aby integracja była odporna na wielokrotne otrzymanie tego samego zdarzenia.

Jak rozpoznawać podwójne zamówienia na podstawie identyfikatorów Shopify?

Najważniejszą zasadą jest odróżnienie identyfikatora powiadomienia od identyfikatora rzeczywistego zamówienia. Shopify udostępnia kilka różnych wartości, które pełnią odmienne funkcje.

• Shopify Order ID — identyfikuje konkretne zamówienie w sklepie. Powinien stanowić podstawę rozpoznawania tej samej transakcji w systemach zewnętrznych.
• Shopify Customer ID — identyfikuje rekord klienta w Shopify. Może być wykorzystywany do powiązania klienta z odpowiednim rekordem CRM.
• X-Shopify-Webhook-Id — identyfikuje pojedyncze dostarczenie webhooka i pozwala rozpoznać ponowienie tego samego powiadomienia.
• X-Shopify-Event-Id — pozwala powiązać dostarczenia webhooków pochodzące z tego samego działania w sklepie.

Różnica ma fundamentalne znaczenie. Dla jednego zamówienia mogą pojawić się oddzielne powiadomienia orders/create i orders/updated. Każde może mieć inny identyfikator webhooka, ale oba dotyczą tego samego zamówienia Shopify. Dlatego sprawdzanie wyłącznie X-Shopify-Webhook-Id chroni przed niektórymi powtórnymi dostarczeniami, ale nie zapobiega tworzeniu tego samego zamówienia przez kilka niezależnych procedur.

W integracjach obsługujących kilka sklepów bezpieczne rozpoznawanie transakcji powinno uwzględniać również identyfikator sklepu. Numer zamówienia pochodzący z jednego konta Shopify nie powinien być traktowany jako globalnie unikalny w całym systemie obejmującym wielu sprzedawców. Podstawą identyfikacji może być więc połączenie identyfikatora sklepu i trwałego identyfikatora zamówienia.

Nie należy natomiast wykorzystywać samego adresu e-mail jako jedynego klucza identyfikującego klienta. Adres może zostać zmieniony, a sposób obsługi zamówień gościnnych może różnić się od obsługi klientów posiadających konto. Do synchronizacji rekordów Shopify zdecydowanie lepiej nadaje się identyfikator klienta nadany przez platformę.

Jak podwójne zamówienia w CRM mogą zawyżać przychody i wskaźniki rentowności?

Duplikaty stają się szczególnie niebezpieczne wtedy, gdy przedsiębiorstwo wykorzystuje system CRM jako główne źródło danych sprzedażowych. Wiele firm łączy w jednym raporcie informacje o zamówieniach, kosztach reklamowych, marży produktów i wartości klientów. Jeżeli CRM zawiera transakcje zapisane dwukrotnie, wynik analizy może przedstawiać sprzedaż większą niż rzeczywiście zrealizowana.

Rozważmy przykład sklepu, który w ciągu miesiąca zarejestrował w Shopify 500 opłaconych zamówień o łącznej wartości 100 000 zł. W wyniku błędu integracji system CRM przechowuje 530 rekordów, a suma wartości transakcji wynosi 106 000 zł. Oznacza to, że zewnętrzny system raportuje przychód zawyżony o 6000 zł, czyli o 6%.

Załóżmy, że sklep w tym samym okresie wydał 25 000 zł na reklamy. Jeśli wewnętrzny dashboard dzieli całkowity przychód przez koszt reklam, otrzymamy następujące wartości:

• Dane Shopify: 100 000 zł przychodu / 25 000 zł kosztów reklam = 400%.
• Dane CRM z duplikatami: 106 000 zł przychodu / 25 000 zł kosztów reklam = 424%.

W tym uproszczonym przykładzie wskaźnik obliczony na podstawie CRM jest zawyżony o 24 punkty procentowe. Należy jednak prawidłowo interpretować jego znaczenie. Jeśli przychód obejmuje wszystkie zamówienia sklepu, a mianownik wyłącznie wydatki reklamowe, jest to wskaźnik przychodów do wydatków marketingowych, często określany jako MER, a nie ROAS przypisany konkretnej kampanii Google Ads.

Raport może wyglądać lepiej mimo braku jakiejkolwiek dodatkowej sprzedaży. Problem staje się jeszcze poważniejszy, gdy przedsiębiorstwo wykorzystuje zawyżone dane do obliczania marży, planowania zakupów magazynowych albo oceny skuteczności agencji reklamowej. Błędny obraz wyników może prowadzić do decyzji o zwiększaniu wydatków, które nie mają pokrycia w rzeczywistym zysku.

Czy podwójne rekordy Shopify w CRM automatycznie zawyżają konwersje Google Ads i GA4?

Nie. Samo utworzenie duplikatu w CRM nie oznacza, że Google Ads lub Google Analytics 4 zarejestrują dodatkową konwersję. Wszystko zależy od sposobu przekazywania danych pomiędzy systemami.

Jeżeli Google Ads korzysta z niezależnego tagu śledzącego zakupy bezpośrednio w Shopify, a CRM służy wyłącznie do obsługi klientów, podwójne rekordy w CRM mogą nie mieć żadnego wpływu na liczbę konwersji w panelu reklamowym. W takiej sytuacji rozbieżność będzie widoczna przede wszystkim podczas porównywania raportów sprzedażowych.

Inaczej wygląda sytuacja, gdy CRM stanowi źródło konwersji importowanych do Google Ads albo przekazuje informacje o wartości zamówień do narzędzi analitycznych. Jeśli każde zdublowane zamówienie jest traktowane jako osobna transakcja i otrzymuje inny identyfikator, system reklamowy może otrzymać nieprawidłowe dane.

Dlaczego transaction_id jest tak ważny?

Google Ads zaleca wykorzystywanie unikalnego identyfikatora transakcji, aby ograniczać podwójne liczenie zakupów. Jeśli dla tej samej akcji konwersji pojawią się dwa zgłoszenia z takim samym identyfikatorem transakcji, Google Ads może rozpoznać drugi wpis jako duplikat i pominąć go.

Identyfikator powinien być generowany dynamicznie i odpowiadać rzeczywistemu zamówieniu. Nie należy przesyłać losowego, nowego identyfikatora przy każdym ponownym przetworzeniu tego samego zakupu. Jeśli oba rekordy CRM dotyczą tej samej transakcji Shopify, powinny zachowywać spójny identyfikator źródłowy.

Podobny mechanizm istnieje w Google Analytics 4. Google wykorzystuje parametr transaction_id do ograniczania duplikatów zdarzeń purchase zbieranych przez strumienie internetowe. Ważne jest jednak, aby nie przekazywać pustego identyfikatora ani tej samej wartości dla różnych rzeczywistych zamówień, ponieważ może to prowadzić do pomijania prawidłowych transakcji.

Nie należy zakładać, że wszystkie mechanizmy deduplikacji działają identycznie w różnych źródłach danych i akcjach konwersji. Konieczne jest sprawdzenie konfiguracji konkretnej integracji, a nie wyłącznie obecności parametru transaction_id.

Jak krok po kroku wykryć podwójne zamówienia między Shopify a CRM?

Ustal rzeczywistą liczbę zamówień w Shopify

Rozpocznij od panelu Shopify i wybierz określony przedział dat. Przygotuj zestawienie zamówień, uwzględniając ich trwałe identyfikatory, daty utworzenia, wartości i statusy płatności. Trzeba jasno ustalić, czy analizujesz wszystkie zamówienia, czy wyłącznie transakcje opłacone. Nie należy mieszać zamówień anulowanych, oczekujących na płatność i zakończonych bez zastosowania odpowiednich zasad ich uwzględniania.

Porównaj unikalne identyfikatory zamówień z CRM

Następnie sprawdź, czy każdy identyfikator zamówienia Shopify występuje w CRM dokładnie raz jako jedna transakcja biznesowa. Jeżeli ten sam identyfikator został przypisany do kilku rekordów, prawdopodobnie występuje duplikacja. Warto jednocześnie wyszukać zamówienia zapisane w CRM bez identyfikatora źródłowego, ponieważ ich powiązanie ze sklepem może wymagać dodatkowej weryfikacji.

W przypadku systemów wykorzystujących relacyjną bazę danych można posłużyć się przykładowym zapytaniem:

SELECT
    shop_domain,
    shopify_order_id,
    COUNT(*) AS liczba_rekordow
FROM crm_orders
GROUP BY
    shop_domain,
    shopify_order_id
HAVING COUNT(*) > 1;

Zapytanie zakłada, że baza posiada odpowiednie kolumny i nazwy tabel. Pozwala odnaleźć identyfikatory transakcji występujące wielokrotnie. Wynik należy jednak interpretować zgodnie ze strukturą konkretnego systemu, ponieważ niektóre aplikacje przechowują historię zmian zamówienia jako wiele technicznych rekordów. Samo powtórzenie identyfikatora w tabeli historii nie musi oznaczać zdublowanej sprzedaży.

Sprawdź moment utworzenia duplikatów

Jeżeli kilka rekordów zostało utworzonych w odstępie ułamków sekundy, może to wskazywać na równoległe przetwarzanie webhooków. Jeśli duplikat powstał po kilku minutach lub godzinach, warto sprawdzić ponowienia dostarczeń, błędy połączeń i działanie mechanizmów synchronizacji okresowej.

Pomocne będą logi zawierające identyfikator sklepu, typ webhooka, identyfikator powiadomienia, identyfikator zamówienia i wynik zapisu w CRM. Takie informacje pozwalają ustalić, czy problem powstaje podczas tworzenia nowych rekordów, czy przy późniejszych aktualizacjach.

Porównaj przychody i liczbę klientów

Po znalezieniu duplikatów należy ustalić, czy zostały uwzględnione w raportach biznesowych. Warto osobno porównać liczbę transakcji, sumę przychodów, średnią wartość zamówienia i liczbę unikalnych klientów. Duplikaty zamówień mogą zawyżać przychody, natomiast powtarzające się rekordy klientów mogą zniekształcać analizę powracających kupujących i wartość klienta w czasie.

Jak naprawić integrację Shopify z Microsoft Dynamics CRM?

Podstawowym rozwiązaniem jest zapewnienie, aby zapis pojedynczego zamówienia był operacją idempotentną. Oznacza to, że wielokrotne wykonanie tej samej operacji nie powinno prowadzić do utworzenia kolejnych niezależnych zamówień.

W praktyce można wykorzystać operację upsert, która aktualizuje rekord, jeżeli już istnieje, albo tworzy nowy, jeżeli system nie posiada jeszcze danej transakcji. Samo wykonanie dwóch oddzielnych operacji — najpierw wyszukania rekordu, a potem jego utworzenia — nie jest wystarczającym zabezpieczeniem przed równoległymi webhookami. Dwa procesy mogą bowiem jednocześnie stwierdzić, że rekord nie istnieje.

W Microsoft Dataverse można wykorzystać klucze alternatywne, czyli alternate keys. Pozwalają one identyfikować rekord na podstawie wartości pochodzących z zewnętrznego systemu. Dla zamówień takim kluczem może być połączenie identyfikatora sklepu oraz identyfikatora zamówienia Shopify. Dla klientów analogicznie można wykorzystać identyfikator sklepu i identyfikator klienta.

Po odpowiednim skonfigurowaniu kluczy aplikacja może wykorzystywać operację upsert dostępną w Dataverse Web API. Jeżeli rekord został już utworzony przez inny proces, kolejne wywołanie powinno odwołać się do tego samego rekordu zamiast tworzyć nowy.

Przy konfiguracji trzeba uwzględnić ograniczenia techniczne kluczy alternatywnych. Microsoft wskazuje, że niektóre znaki specjalne w ich wartościach mogą powodować problemy podczas operacji wykonywanych przez Web API. Dlatego identyfikatory Shopify zapisywane jako klucze należy odpowiednio przygotować i zweryfikować. Trzeba także upewnić się, że klucz osiągnął aktywny status przed rozpoczęciem właściwego przetwarzania danych.

Jeśli integracja korzysta ze starszej wersji Microsoft Dynamics bez odpowiednich funkcji Dataverse, można zastosować pośrednią bazę danych wymuszającą unikalność identyfikatorów. W takim rozwiązaniu aplikacja najpierw zapisuje informację o zamówieniu w kontrolowanej bazie, a dopiero później przekazuje ją do CRM. Mechanizm wymaga również bezpiecznego obsługiwania błędów i ponawiania operacji, aby nie zastąpić problemu duplikatów problemem brakujących transakcji.

Dlaczego samo sprawdzanie X-Shopify-Webhook-Id nie wystarcza?

Shopify zaleca rozpoznawanie powtórnych dostarczeń za pomocą nagłówka X-Shopify-Webhook-Id. Jest to ważne zabezpieczenie, ale rozwiązuje tylko jeden rodzaj problemu.

Załóżmy, że Shopify wysyła powiadomienie orders/create, a serwer nie potwierdza jego odbioru. Shopify ponawia wysłanie tego samego webhooka. W takiej sytuacji aplikacja może sprawdzić identyfikator dostarczenia i pominąć ponowne przetwarzanie, jeśli zdarzenie zostało już skutecznie zapisane.

Jednak powiadomienie orders/updated dotyczące tego samego zamówienia będzie innym dostarczeniem. Jeśli oba typy zdarzeń uruchamiają procedurę tworzenia zamówień, kontrola X-Shopify-Webhook-Id nie wystarczy. Konieczna jest również unikalność identyfikatora samej transakcji w CRM.

Podczas projektowania integracji należy więc stosować dwa odrębne mechanizmy:

• Rozpoznawanie ponownie dostarczonych powiadomień na podstawie identyfikatorów webhooków.
• Zapewnienie unikalności rekordów biznesowych na podstawie identyfikatorów Shopify Order ID i Customer ID.

Dodatkowym zabezpieczeniem jest kolejka przetwarzania. Pozwala ona przyjmować webhooki bez wykonywania długotrwałych operacji CRM bezpośrednio w żądaniu HTTP. Serwer powinien zweryfikować autentyczność powiadomienia za pomocą podpisu HMAC, trwale zapisać zadanie do przetworzenia i szybko potwierdzić jego przyjęcie. Następnie zadanie może zostać wykonane przez osobny proces obsługujący kolejkę.

Takie rozwiązanie zmniejsza ryzyko przekroczenia limitów czasu Shopify i ułatwia ponawianie nieudanych operacji. Sama kolejka nie gwarantuje jednak braku duplikatów. Ostatecznym zabezpieczeniem powinno pozostać wymuszanie unikalności rekordów oraz odporność operacji zapisu na wielokrotne wykonanie.

Jak bezpiecznie usunąć podwójne zamówienia i klientów, które już znajdują się w CRM?

Wykrycie duplikatów nie oznacza, że należy natychmiast usuwać wszystkie powtarzające się rekordy. W CRM mogą być do nich przypisane płatności, dokumenty, notatki handlowe, zgłoszenia obsługi klienta oraz inne informacje. Usunięcie niewłaściwego rekordu może doprowadzić do utraty ważnych powiązań biznesowych.

Przed naprawą należy przygotować kopię danych i zestawienie transakcji wymagających weryfikacji. Następnie trzeba ustalić, który rekord odpowiada rzeczywistemu zamówieniu Shopify oraz czy pozostałe wpisy są faktycznymi duplikatami, a nie odrębnymi operacjami dotyczącymi tej samej transakcji.

W przypadku klientów warto sprawdzić, czy podwójne rekordy nie zawierają różnych informacji, które należy zachować. Po scaleniu danych konieczne jest skontrolowanie relacji pomiędzy klientami i zamówieniami, aby historia zakupów pozostała kompletna.

Szczególnej ostrożności wymagają integracje, w których CRM uruchamia dodatkowe operacje, takie jak wystawianie faktur, wysyłanie wiadomości, aktualizowanie stanów magazynowych czy przekazywanie danych do systemów finansowych. Przed ponownym przetworzeniem historycznych zamówień należy upewnić się, że takie działania nie zostaną wykonane drugi raz.

Po usunięciu nieprawidłowych rekordów warto ponownie przeliczyć raporty sprzedażowe za okres, w którym występował problem. Jeżeli dane CRM były wykorzystywane również w zewnętrznych dashboardach lub hurtowniach danych, konieczne może być odświeżenie odpowiednich zestawień. Nie należy zakładać, że poprawienie bazy CRM automatycznie skoryguje wszystkie wcześniej wygenerowane raporty.

Jak regularnie kontrolować zgodność danych Shopify, CRM, GA4 i Google Ads?

Najlepszym zabezpieczeniem przed długotrwałym zawyżaniem wyników jest cykliczne porównywanie informacji z niezależnych źródeł. Shopify powinien stanowić punkt odniesienia dla liczby rzeczywiście utworzonych zamówień, przy uwzględnieniu statusów płatności i ewentualnych zwrotów. CRM pozwala natomiast ocenić, czy transakcje i klienci zostali prawidłowo odwzorowani w systemie obsługi sprzedaży.

W praktyce warto monitorować kilka wskaźników:

• Liczba zamówień Shopify i CRM — porównywanie unikalnych transakcji za ten sam okres.
• Duplikaty identyfikatorów — wykrywanie zamówień i klientów zapisanych wielokrotnie.
• Zgodność przychodów — kontrola wartości zamówień po uwzględnieniu statusów, rabatów i zwrotów.
• Kompletność synchronizacji — identyfikowanie zamówień obecnych w Shopify, ale nieobecnych w CRM.
• Jakość pomiaru konwersji — porównywanie zdarzeń zakupowych GA4 i działań powodujących konwersję w Google Ads.
• Spójność raportów finansowych — sprawdzanie, czy dashboardy nie sumują technicznych duplikatów jako niezależnych transakcji.

Warto również rozdzielić wskaźniki dotyczące skuteczności reklam od wskaźników całkowitej sprzedaży. Google Ads pokazuje konwersje przypisane reklamom według własnych zasad atrybucji, natomiast Shopify przechowuje rzeczywiste zamówienia niezależnie od źródła pozyskania klienta. Różnica między tymi liczbami nie jest automatycznie błędem. Problemem staje się sytuacja, w której pojedyncze zamówienie jest powielane i traktowane jako kilka transakcji w tym samym zbiorze danych.

Przy ocenie rentowności kampanii pomocne są niezależne analizy danych z Google Ads, GA4 i pozostałych źródeł sprzedażowych. Pozwalają one oddzielić rzeczywiste wyniki reklam od błędów raportowania, które mogą prowadzić do podejmowania nieuzasadnionych decyzji dotyczących budżetu. Do porównań nie zawsze są potrzebne dane osobowe klientów. W wielu przypadkach można wykorzystać statystyki zagregowane, kontrolne zestawienia identyfikatorów przygotowane po stronie sklepu oraz informacje o liczbie i wartości transakcji.

Najczęstsze pytania o podwójne zamówienia Shopify i błędne dane CRM

Czy Shopify samodzielnie tworzy podwójne zamówienia?

Opisany przypadek dotyczy duplikowania rekordów przez zewnętrzną integrację z CRM, a nie potwierdzonego tworzenia podwójnych zamówień w samym Shopify. Problem wynika z równoczesnego przetwarzania webhooków i braku skutecznego rozpoznawania istniejących rekordów. Należy więc ustalić, w którym systemie pojawiają się duplikaty.

Dlaczego to samo zamówienie może wywołać kilka webhooków?

Jedno zamówienie może powodować kilka różnych zdarzeń, między innymi utworzenie zamówienia, aktualizację danych klienta lub zmianę statusu transakcji. Shopify może również ponawiać dostarczenie powiadomienia, jeśli wcześniejsza próba nie została prawidłowo potwierdzona. Integracja powinna bezpiecznie obsługiwać zarówno oddzielne zdarzenia, jak i ponowne dostarczenia.

Czy X-Shopify-Webhook-Id wystarczy do usuwania duplikatów?

Nie. Nagłówek pomaga rozpoznać ponownie dostarczone powiadomienie, ale różne webhooki dotyczące tej samej transakcji mogą mieć odmienne identyfikatory. Do ochrony przed powielaniem zamówień potrzebna jest dodatkowa kontrola oparta na trwałym identyfikatorze Shopify Order ID.

Czy podwójne rekordy CRM mogą zawyżyć ROAS w Google Ads?

Tak, jeśli CRM przekazuje zdublowane transakcje jako odrębne konwersje i system nie rozpoznaje ich jako powtórzeń. Sam fakt występowania duplikatów w CRM nie oznacza jednak automatycznie zawyżenia wyników Google Ads. Wszystko zależy od źródła konwersji, sposobu przekazywania identyfikatorów oraz konfiguracji działań powodujących konwersję.

Czy Google Analytics 4 automatycznie usuwa podwójne zakupy?

GA4 wykorzystuje parametr transaction_id do deduplikacji zdarzeń zakupu zbieranych przez strumienie internetowe. Mechanizm wymaga prawidłowo przekazywanych, unikalnych identyfikatorów. Nie należy jednak zakładać, że GA4 automatycznie naprawi nieprawidłowe dane w CRM lub wszystkich zewnętrznych systemach analitycznych.

Jak najlepiej zabezpieczyć Microsoft Dynamics przed duplikatami Shopify?

W Microsoft Dynamics 365 wykorzystując

admin

Materiały o e-commerce, sprzedaży i technologii dla sklepów internetowych.