Ten przewodnik zawiera wymagania, rekomendacje dotyczące modelowania danych i sprawdzone metody wdrażania kart podarunkowych (znanych też jako bony) w pliku danych z ofertami. Te rekomendacje uzupełniają standardową dokumentację Centrum działań i dotyczą aspektów integracji specyficznych dla kart podarunkowych.
Tryb oferty i kategoryzacja
Przesyłając informacje o kartach podarunkowych, upewnij się, że te podstawowe atrybuty są prawidłowo skonfigurowane:
Tryb oferty:
offer_modesmusi być zawsze ustawiony jako tablica singleton zawierająca wartość"OFFER_MODE_GIFT_CARD_PURCHASE":"offer_modes": ["OFFER_MODE_GIFT_CARD_PURCHASE"]Bony o określonej wartości a rabaty natychmiastowe w sklepie:
gift_card_infojest zarezerwowany wyłącznie dla wcześniej zakupionych bonów i kart podarunkowych o określonej wartości (OFFER_MODE_GIFT_CARD_PURCHASE).- Jeśli klient płaci bezpośrednio przy kasie w sklepie stacjonarnym, aby otrzymać natychmiastowy rabat, bez kupowania kodu bonu do wykorzystania w późniejszym terminie, modeluj ofertę jako standardowy rabat w sklepie (
OFFER_MODE_WALK_IN) i całkowicie pomiń komunikatgift_card_info.
Modelowanie nominałów: nominał karty podarunkowej powinien odzwierciedlać wartość bonu (za co można go wykorzystać), a nie kwotę, którą płaci użytkownik (użytkownik płaci cenę z rabatem).
Łączenie wielu nominałów: kilka bonów z tym samym procentem rabatu i tymi samymi warunkami, ale różnymi wartościami nominalnymi, musi być zgrupowanych w jedną pozycję oferty. Ponieważ
denomination_typedziała jakooneof, partnerzy muszą wybrać między ustawieniemfixed_denominationsacustom_range:- Stałe nominały: używaj, gdy oferowane są dyskretne, wstępnie ustawione kwoty kart podarunkowych (np. 500, 1000 i 2000 PLN, wszystkie z rabatem 10%). Upewnij się, że wszystkie stałe nominały, które są wyprzedane lub niedostępne na stronie docelowej, są wyraźnie wykluczone z przesłanych plików danych.
- Zakres niestandardowy: używaj tylko wtedy, gdy użytkownicy mogą swobodnie wpisać dowolną
wartość nominalną w zdefiniowanych granicach na stronie zakupu (np. dowolną wartość
od 100 do 5000 PLN z rabatem 5%). Jeśli strona docelowa oferuje dyskretne, wstępnie ustawione kwoty, modeluj zasoby wyłącznie w sekcji
fixed_denominations. Jeśli w ofercie dostępne są zarówno stałe, jak i niestandardowe nominały, partnerzy powinni ustawić elastyczny zakres niestandardowy.
Nieobsługiwane funkcje: progi minimalnego zakupu / minimalnej kwoty rachunku (min_spend_value)
Dlaczego bony z minimalną kwotą rachunku nie są obsługiwane
Oferty wymagające minimalnej kwoty transakcji, aby wykorzystać bon o określonej wartości (na przykład: "Kup bon o wartości 800 PLN za 150 PLN, który można wykorzystać tylko przy minimalnym rachunku w wysokości 5000 PLN lub wyższej") wykraczają poza obecny zakres integracji ofert w Centrum działań z tych powodów:
- Wprowadzające w błąd i nieintuicyjne wrażenia użytkownika: obliczanie procentów rabatu (
discount_percent) przez połączenie ceny zakupu bonu z hipotetyczną minimalną kwotą rachunku tworzy dla użytkowników wprowadzające w błąd i nieintuicyjne twierdzenia o oszczędnościach. - Niezgodna struktura pliku danych: standardowe pliki danych kart podarunkowych zakładają, że wartość nominalna (
fixed_denominationslubcustom_range) jest w pełni wykorzystywana do dowolnego zakupu w sklepie bez warunkowych ograniczeń dotyczących rachunku. - Niska liczba transakcji w branży: te warunkowe oferty bonów z minimalną kwotą rachunku mają niską łączną liczbę transakcji i wymagają specjalnego traktowania, które różni się od standardowych kart podarunkowych o określonej wartości.
Działanie wymagane od partnerów
Jeśli Twoje zasoby obejmują promocje bonów z warunkową minimalną kwotą rachunku:
- Usuń z pliku danych: nie przesyłaj warunkowych bonów podarunkowych z minimalną kwotą rachunku za pomocą
OFFER_MODE_GIFT_CARD_PURCHASE(ani nie próbuj tego obejść, przesyłając je za pomocąOFFER_MODE_WALK_IN). Całkowicie usuń te konkretne promocje z eksportów pliku danych. - Prośba o ponowne rozważenie funkcji: jeśli uważasz, że te warunkowe bony z minimalną kwotą rachunku mają znaczną wartość biznesową, możesz udostępnić dane szczegółowo opisujące wpływ na zasięg sprzedawcy, współczynniki konwersji transakcji i ogólną liczbę transakcji swojemu kontaktowi w Google. Nasz zespół inżynierów może przeanalizować te dane, aby ocenić potencjalne przyszłe wsparcie. Pamiętaj jednak, że udostępnienie danych nie gwarantuje, że ta funkcja będzie traktowana priorytetowo ani obsługiwana.
Obsługa sieci sklepów w wielu lokalizacjach
W przypadku bonów podarunkowych, które obowiązują w dużych sieciach handlowych lub gastronomicznych, gdzie warunki są identyczne w wielu punktach zainteresowania, nie podawaj osobnego obiektu Offer dla każdej lokalizacji sklepu. Zamiast tego użyj zbiorczego podejścia do przesyłania danych, podając jeden obiekt Offer zawierający listę wszystkich identyfikatorów podmiotów sklepu uczestniczących w programie (entity_ids).
Branding portalu (brand_id)
Niektóre bony są oferowane za pośrednictwem określonych portali bankowych lub lojalnościowych (np. programów lojalnościowych banków lub platform partnerskich), a nie głównej witryny sprzedawcy. Aby zapewnić dokładny branding tych portali, partnerzy muszą wypełnić pole brand_id w obiektach Offer najwyższego poziomu.
Pominięcie brand_id powoduje domyślne ustawienie głównej marki konta (a brand_id nie jest wymagany, gdy używasz domyślnej marki konta), ale wyraźne wypełnienie brand_id dokładnie powiąże zasoby z odpowiednim portalem marki, dzięki czemu użytkownicy będą widzieć prawidłowe logo i nazwy partnerów. Więcej informacji o konfigurowaniu marek znajdziesz w artykule
Konfiguracja marek.
Struktura ważności (ValidityScope)
Karty podarunkowe mają unikalną strukturę ważności, która odróżnia czas zakupu oferty od czasu wykorzystania karty. Partnerzy muszą zawsze używać odpowiednich wartości wyliczeniowych ValidityScope:
VALIDITY_SCOPE_CLAIM: określa czas, w którym oferta karty podarunkowej jest dostępna do zakupu na platformie partnera. Ten wpis musi być zawsze obecny. Przesyłając pliki danych, wypełnij okres ważności roszczenia, zaczynając od dokładnej daty przesłania pliku danych. Ponadto nigdy nie pozostawiaj okresów roszczeń otwartych, jeśli strona docelowa wyraźnie reklamuje datę zakończenia kampanii. Dopasujvalid_through_timedo reklamowanej daty ważności.VALIDITY_SCOPE_REDEEM: określa czas wykorzystania po zakupie (czas, w którym użytkownicy mogą wykorzystać bon w sklepie po jego zakupie, który można określić jako czas trwania lub okres).
Mapowanie typu działania
Partnerzy często kategoryzują bony za pomocą konstrukcji takich jak „można wykorzystać online/offline”, „online/outlet” lub „w sklepie”. W przesłanych plikach danych należy to zmapować na wyliczenie ActionType, aby dokładnie określić, jak produkt jest wykorzystywany:
- Branża gastronomiczna: mapuj karty podarunkowe „Dine-in” na
ACTION_TYPE_DINING. Mapuj karty podarunkowe „Dostawa” naACTION_TYPE_FOOD_DELIVERY. Mapuj karty podarunkowe „Na wynos” naACTION_TYPE_FOOD_TAKEOUT. - Branża handlowa: mapuj karty podarunkowe „W sklepie” na
ACTION_TYPE_SHOPPING_IN_STORE. (Uwaga: bony handlowe tylko online nie są obsługiwane). - Mapowanie pojedynczego kanału: każdy
offer_idmoże należeć do dokładnie jednegoActionType. Jeśli produkt obsługuje wiele kanałów realizacji (np. dostawę jedzenia i odbiór osobisty), utwórz osobne obiekty Offer z unikalnymi identyfikatorami dla każdego trybu.
Rabaty warstwowe i oferty dodatkowe
- Rabaty warstwowe w zależności od formy płatności: jeśli oferowane są różne procenty rabatu w zależności od użytej formy płatności (np. wyższy rabat w przypadku e-portfela niż w przypadku kart kredytowych), należy je modelować jako osobne obiekty Offer. Aby zapewnić niezawodne oszczędności, partnerzy powinni zapewnić wyczerpujące pokrycie promocyjne we wszystkich obsługiwanych formach płatności (np. e-portfele, karty kredytowe, karty debetowe, bankowość internetowa). Jeśli oferta obowiązuje powszechnie we wszystkich formach płatności akceptowanych na platformie, pole formy płatności nie powinno być ustawione.
- Konstrukcja ofert dodatkowych: aby przedstawić korzyści, takie jak
punkty lojalnościowe specyficzne dla banku lub dodatkowy zwrot gotówki za zakup karty podarunkowej
, prześlij je jako całkowicie osobne oferty dodatkowe, używając odpowiedniego
wyliczenia
OfferCategory–OFFER_CATEGORY_ADD_ON_PAYMENT_OFFER. Opisz nagrodę wOfferDetails.other_offer_details_text(np., "Do 5 razy więcej punktów lojalnościowych") i połącz ją z podstawową ofertą karty podarunkowej, wypełniającOfferRestrictions.combinable_offer_idswartościąoffer_idpodstawowej karty podarunkowej.
Warunki i warunki specjalne
Partnerzy powinni używać terms.terms_and_conditions, aby podać pełne warunki prawne karty podarunkowej lub bonu. W tym polu należy umieścić wszystkie instrukcje i wytyczne dotyczące użytkowania, które są widoczne dla użytkowników.
Jeśli krytyczne ograniczenia wymagają specjalnego wyróżnienia w interfejsie (np. wygaśnięcie salda jednorazowego użytku, brak możliwości zwrotu lub limity łączenia transakcji, takie jak
„Maksymalnie 2 bony można połączyć na rachunek”), wyróżnij je w
offer_restrictions.special_conditions.
Rekomendacje dotyczące tytułu oferty
Długość tytułu oferty nie powinna przekraczać 40 znaków. Usuń nazwy marek sprzedawców z offer_display_text, ponieważ oferty są wyświetlane bezpośrednio na stronie sprzedawcy. Zalecamy stosowanie tych formatów tytułów:
| Przypadek użycia | Zalecany tytuł |
|---|---|
| Rabat stały na bony | X% off on Gift Cards |
| Rabat zmienny w zależności od formy płatności | X% off on Gift Cards using {e-wallet}
|
| Rabaty zmienne na różne nominały | X% off on Gift Cards (Przesyłaj różne
rabaty jako osobne oferty) |
| Karty podarunkowe B2B2C | X% off on Gift Cards (Branding jest
wyświetlany za pomocą miniatury z użyciem
brand_id) |
| Oferty dodatkowe | Flat/Up to 5X reward points/
<Platform> coins |
Wymagania dotyczące strony docelowej
Każdy reklamowany offer_url musi zwracać kod HTTP 200 OK bezpośrednio, bez przekierowań pośrednich, i prowadzić do aktywnej strony docelowej potwierdzającej ofertę.
Plik danych nie może zawierać wyprzedanych ani niedostępnych nominałów. Utrzymuj ścisłą synchronizację zasobów między polami nominałów w pliku danych a opcjami zakupu na żywo na stronie docelowej.
Strona docelowa powinna wyraźnie informować, że oferta dotyczy konkretnie kart podarunkowych lub bonów.
Jeśli na przykład strona docelowa partnera wyświetla tylko ogólne wezwania do działania dotyczące płatności, takie jak „Zapłać rachunek”, bez wyraźnego stwierdzenia, że po zakończeniu transakcji zostanie wydany bon o określonej wartości, użytkownicy przekierowani z Google, którzy chcą kupić kartę podarunkową, mogą być zdezorientowani lub zrezygnować. Nawet jeśli powiadomienie o bonie pojawi się na kolejnym etapie płatności, wymagana jest przejrzystość na początkowej stronie docelowej.
Oferty z kodami kuponów
Niektóre oferty wymagają wpisania przez użytkownika kodu kuponu, np. „Zastosuj kod SAVE20, aby otrzymać 20% rabatu na łączną kwotę rachunku”. Pamiętaj, że Google nie wyświetla kodów kuponów z definicji kuponu. Partnerzy mogą umieścić te informacje w OfferDetails.offer_display_text , aby były widoczne dla użytkowników. Oferty oparte na kuponach dzielą się na 2 kategorie:
- Oferty, w których kupon jest automatycznie prezentowany przy płatności każdemu użytkownikowi, który trafił na stronę z Google. Są one dozwolone.
- Oferty, które wymagają od użytkownika wpisania kodu kuponu przy płatności, ale nie zawierają instrukcji, jak zastosować kod kuponu na stronie docelowej adresu URL oferty, lub nie stosują automatycznie kuponu po kliknięciu adresu URL oferty, są niedozwolone.
Przykład oferty karty podarunkowej w formacie JSON
{
"data": [
{
"offer_id": "example-dining-gift-card-10off",
"entity_ids": [
"dining-1",
"dining-2"
],
"offer_modes": [
"OFFER_MODE_GIFT_CARD_PURCHASE"
],
"action_type": "ACTION_TYPE_DINING",
"offer_source": "OFFER_SOURCE_AGGREGATOR",
"offer_category": "OFFER_CATEGORY_BASE_OFFER",
"offer_details": {
"offer_display_text": "10% off on Gift Cards",
"discount_percent": 10.0,
"gift_card_info": {
"fixed_denominations": {
"amounts": [
{
"units": 500,
"currency_code": "INR"
},
{
"units": 1000,
"currency_code": "INR"
},
{
"units": 2000,
"currency_code": "INR"
}
]
}
}
},
"offer_restrictions": {
"combinable_with_other_offers": false,
"special_conditions": [
"Single-use balance expiration applies",
"Maximum 2 gift card vouchers can be combined per bill",
"No cash refund will be provided against this voucher"
]
},
"terms": {
"restricted_to_certain_users": false,
"terms_and_conditions": "1. Redeemable exclusively at participating dining outlets.\n2. Single-use balance expiration applies.\n3. Maximum 2 gift card vouchers can be combined per bill.\n4. No cash refund will be provided against this voucher."
},
"validity_periods": [
{
"valid_period": {
"valid_from_time": {
"seconds": "1774934350"
},
"valid_through_time": {
"seconds": "1806470350"
}
},
"validity_scope": "VALIDITY_SCOPE_CLAIM"
},
{
"validity_duration_in_days": 365,
"validity_scope": "VALIDITY_SCOPE_REDEEM"
}
],
"offer_url": "https://www.example-portal.com/dining-gift-cards/buy"
}
]
}