FluentCRM nie nadaje tagów po zakupie? Sprawdź, które meta czytasz

Zamówienie opłacone, a według audytu nikt nie dostaje tagu

Otwieramy sklep kursowy klientki. Czternaście produktów: kursy, mentoring, bilety na wydarzenia. Sprawdzamy skryptem, które z nich nadają tag po zakupie, bo od tego tagu zależy dostęp do materiałów i cała sekwencja maili powitalnych. Wynik: dwanaście produktów z pustą konfiguracją.

Dwanaście na czternaście. Wyglądało to tak, jakby prawie cały sklep sprzedawał, a kupujące nie dostawały nic. Przez pierwsze pół godziny byliśmy pewni, że FluentCRM nie nadaje tagów po zakupie. I był to fałszywy alarm od początku do końca – patrzyliśmy w niewłaściwe miejsce w bazie. Przy okazji znaleźliśmy jednak drugą pułapkę, która w wielu sklepach kursowych realnie odbiera klientkom opłacony dostęp.

Kontekst: platforma, w której tag jest kluczem do kursu

Klientka prowadzi platformę kursową na WordPressie z WooCommerce. Sprzedaje kursy jednorazowo i w abonamencie, do tego mentoring i bilety. Dostępu do materiałów nie pilnuje samo zamówienie, tylko tag w FluentCRM: kupujesz – dostajesz tag, tag otwiera treści i uruchamia automatyzację mailową. Abonament wygasa – tag schodzi, dostęp się zamyka.

W takim układzie źle wpięty tag to nie kosmetyka. To kursantka, która zapłaciła i nie widzi kursu, albo odwrotnie – ktoś, kto przestał płacić, a dalej ma wszystko. Dlatego konfigurację tagów sprawdzamy przy każdym przejęciu platformy i przed każdą większą kampanią sprzedażową.

Diagnoza: co sprawdzaliśmy, zanim zrozumieliśmy, że to pomiar

Hipoteza 1: konfiguracja zniknęła przy migracji

Pierwsze podejrzenie było naturalne. Strona była wcześniej przenoszona i powstała z klonu szablonu. Odczytaliśmy meta produktów i zobaczyliśmy puste, zserializowane tablice: a:0:{}. Wygląda jednoznacznie – pole istnieje, ale jest puste. Czyli ktoś albo coś je wyczyściło.

Hipoteza 2: wersja wtyczki nie obsługuje tagów przy subskrypcjach

Też nie. Licencja Pro była aktywna, a integracja z WooCommerce działała. Gdyby była martwa, nie ruszałaby żadna automatyzacja po zakupie – a te ruszały, bo maile powitalne wychodziły.

Sygnał, który powinien zapalić lampkę od razu

Sklep sprzedawał od miesięcy, a żadna kursantka nie zgłosiła braku dostępu. Przy „awarii” dwunastu z czternastu produktów skrzynka powinna być pełna reklamacji. Była pusta. To był moment, w którym coś przestało się zgadzać.

Moment odkrycia: dwa klucze meta o mylnie podobnych nazwach

Czytaliśmy meta produktu o kluczu wpf-settings-woo. To konfiguracja WP Fusion – zupełnie innej wtyczki do tagowania, której na tej stronie nie ma. Klucz został w bazie po klonie szablonu i jest pusty, bo nic go nie zapisuje ani nie czyta.

Ustawienia tagów FluentCRM dla produktu WooCommerce siedzą w meta fcrm-settings-woo. Wszystko, co zaczyna się od wpf-, to ślad po WP Fusion i nie mówi nic o Twojej konfiguracji.

Po odczytaniu właściwego klucza obraz odwrócił się całkowicie: komplet tagów był wpięty od początku, w każdym produkcie, poprawnie. Sklep działał dokładnie tak, jak miał działać. Zepsuty był wyłącznie nasz odczyt.

Skąd w ogóle takie śmieci w bazie? WordPress nie sprząta po wtyczkach. Gdy szablon albo wcześniejsza wersja strony miała kiedyś zainstalowane inne narzędzie, jego meta zostają przy produktach na zawsze – także po klonowaniu i migracji. Wyglądają jak żywa konfiguracja, ale nikt ich nie czyta.

Jak sprawdzić tagi produktów u siebie

Komendy uruchamiasz przez WP-CLI na serwerze. 123 podmień na ID produktu. Kolejność ma znaczenie.

# 1. Najpierw: która wtyczka faktycznie zarządza tagami?
wp plugin list --status=active | grep -i -E "fluent|fusion"

# 2. Dopiero potem: właściwe meta produktu (FluentCRM)
wp post meta get 123 fcrm-settings-woo --format=json

# 3. Dla porównania: martwy ślad po WP Fusion (jeśli WP Fusion nie jest aktywny)
wp post meta get 123 wpf-settings-woo

W poprawnie skonfigurowanym produkcie w fcrm-settings-woo zobaczysz klucze: purchase_apply_tags (tag nadawany po zakupie), purchase_remove_tags, refund_apply_tags i refund_remove_tags (zwrot) oraz on_sub_expired_apply_tags i on_sub_expired_remove_tags dla subskrypcji. W panelu to zakładka FluentCRM w edycji produktu WooCommerce.

Przy większej liczbie produktów robimy to pętlą po ID – kilkadziesiąt produktów to kilkanaście sekund i jedyny sensowny sposób na audyt przed startem sprzedaży:

for id in $(wp post list --post_type=product --format=ids); do
  echo "== $id"; wp post meta get $id fcrm-settings-woo --format=json
done

Masz platformę kursową, na której tag decyduje o dostępie, i nie chcesz sam przekopywać meta produktów? Sprawdzenie tagów, maili i zakupu testowego to stały element naszego audytu platformy kursowej – napisz, co sprzedajesz, a powiemy, od czego zacząć.

Druga pułapka: pola Subscription Cancelled Actions

Skoro już byliśmy w konfiguracji, przejrzeliśmy ustawienia subskrypcyjne. I tu jest realny błąd, który popełnia się z najlepszymi intencjami: wypełnienie pól Subscription Cancelled Actions tagiem odbierającym dostęp.

Wygląda logicznie – kursantka anulowała abonament, więc zdejmujemy dostęp. Problem w tym, jak działa WooCommerce Subscriptions. Anulowanie przez kursantkę nie kończy subskrypcji od razu. Dostaje ona status pending-cancel i jest aktywna do końca opłaconego okresu. FluentCRM tego statusu w ogóle nie obsługuje – w akcjach produktu mapuje wyłącznie active, expired, cancelled i payment-failed.

Efekt źle ustawionych pól: tag podpięty pod anulowanie potrafi zabrać dostęp, za który kursantka już zapłaciła. Płaci za miesiąc, po tygodniu klika „nie przedłużaj” i traci kurs. Z jej perspektywy platforma ją okradła – i taka wiadomość trafia potem do właścicielki szkoły.

Nasza zasada na każdej platformie: pola Subscription Cancelled Actions zostają puste. Odcięcie dostępu wisi wyłącznie na on_sub_expired. Świadoma konsekwencja jest taka, że subskrypcja anulowana przed końcem okresu kończy się statusem cancelled, a nie expired, więc tag zamykający dostęp nie zejdzie sam i takie przypadki domykamy ręcznie. To jednak o rząd wielkości mniejszy problem niż odbieranie opłaconego dostępu.

Efekt: zero naprawy, jedna poprawiona procedura

W samym sklepie nie trzeba było niczego naprawiać – tagi działały od początku. Zmieniło się co innego: kolejność, w jakiej robimy audyt.

Checklista audytu tagów na platformie kursowej

1. Wypisz aktywne wtyczki i ustal, która realnie zarządza tagami.
2. Odczytaj fcrm-settings-woo dla każdego produktu, a nie inne meta o podobnej nazwie.
3. Sprawdź, czy każdy produkt ma purchase_apply_tags – to wejście kursantki do kursu.
4. Przy abonamentach sprawdź on_sub_expired_remove_tags – to wyjście.
5. Upewnij się, że Subscription Cancelled Actions są puste.
6. Zrób zakup testowy na własny adres i zobacz, czy tag faktycznie wchodzi, a mail powitalny wychodzi.
7. Zanim ogłosisz awarię, sprawdź, czy klienci ją zgłaszają. Cisza przy „awarii” zwykle oznacza błąd pomiaru.

Więcej o tym, co powinno działać automatycznie od zakupu do pierwszej lekcji, opisaliśmy w poradniku o funkcjach platformy kursowej i w tekście jak sprzedawać kursy online. Podobną historię fałszywego alarmu, tym razem z zamówieniami w stanie „nieudane”, opisaliśmy na blogu o zamówieniu failed, za które klient zapłacił.

Czego nauczyła nas ta historia

Baza WordPressa jest pełna śladów po wtyczkach, których dawno nie ma. Klucz meta nie dowodzi, że coś jest zainstalowane – dowodzi tylko, że kiedyś było. Zanim powiemy właścicielce platformy, że jej sprzedaż nie działa, sprawdzamy stan systemu od strony aktywnych wtyczek, a nie od strony osadu w bazie. Kosztuje to trzy minuty i oszczędza fałszywego alarmu o zepsutym źródle przychodu.

FAQ

Gdzie FluentCRM trzyma ustawienia tagów produktu WooCommerce?

W meta produktu o kluczu fcrm-settings-woo, jako zserializowana tablica. W panelu odpowiada temu zakładka FluentCRM w edycji produktu.

Czym jest meta wpf-settings-woo?

To konfiguracja wtyczki WP Fusion. Jeśli z niej nie korzystasz, ten klucz bywa pusty i nie mówi nic o Twoich tagach, nawet jeśli fizycznie siedzi w bazie po imporcie lub klonie strony.

Dlaczego FluentCRM nie nadaje tagów po zakupie, choć produkt ma ustawiony tag?

Najpierw upewnij się, że to prawda: zrób zakup testowy i sprawdź kontakt w FluentCRM. Jeśli tag faktycznie nie wchodzi, sprawdź w zakładce FluentCRM produktu, czy pole tagu po zakupie jest wypełnione, i czy zamówienie zostało opłacone, a nie utknęło w statusie oczekującym.

Dlaczego tag nie schodzi po anulowaniu subskrypcji?

Bo anulowanie przez klienta daje najpierw status pending-cancel, a subskrypcja trwa do końca opłaconego okresu. Jeśli odcięcie wisi wyłącznie na wygaśnięciu, anulowane subskrypcje trzeba domknąć ręcznie – to świadomy wybór na rzecz uczciwości wobec kursantki.

Czy można sprawdzić tagi wszystkich produktów naraz?

Tak, pętlą po ID produktów w WP-CLI odczytującą fcrm-settings-woo. Przy kilkudziesięciu produktach to kilkanaście sekund.

Co zrobić, gdy produkt naprawdę nie ma wpiętego tagu?

Uzupełnić go w zakładce FluentCRM w edycji produktu i zrobić zakup testowy. Osobno trzeba obsłużyć osoby, które kupiły w międzyczasie – je otagujesz ręcznie na podstawie listy zamówień.