Affiliate Campaigns के लिए Google Enhanced Conversions सेटअप गाइड

Build शुरू करने से पहले: उस conversion की पुष्टि करें जिस पर आप सच में भरोसा करते हैं

पहला setup decision technical नहीं है। यह तय करना है कि कौन-सा event spend guide करने के लिए पर्याप्त भरोसेमंद है।

Payout-grade primary event चुनें

अधिकांश affiliate funnels के लिए सबसे अच्छा primary conversion confirmed sale, approved lead, या payout-verified transaction होता है। Lead form submit, checkout view, या trial start अभी भी उपयोगी हो सकते हैं, लेकिन optimization hierarchy में ये events आमतौर पर final revenue event के नीचे होने चाहिए।

एक clean event model कुछ ऐसा दिख सकता है:

अगर ClickBank या Digistore24 जैसे network user के page छोड़ने के बाद payout confirmation भेजते हैं, तो शुरुआती conversion को pending रखें जब तक network postback status confirm न कर दे। इससे Google Ads ऐसे outcomes से नहीं सीखेगा जो कभी payable revenue नहीं बनते।

Rollout से पहले baseline सेट करें

एक या दो strong days के आधार पर setup को judge न करें। Bids बदलने से पहले कम-से-कम एक normal buying cycle के लिए baseline capture करें।

Implementation से पहले और बाद में ये numbers track करें:

• Reported Google Ads conversions बनाम network-confirmed conversions.
• प्रति दिन duplicate order IDs.
• Postback delay का median और P95.
• Refund या reversal latency.
• Google Ads और आपके ledger के बीच conversion value differences.

Planning estimate के तौर पर, teams अक्सर identifiers के सही तरीके से normalized होने के बाद attributable conversions में meaningful increase की उम्मीद करती हैं। किसी भी expected lift को promise नहीं, hypothesis मानें। असली test यह है कि match quality improve हो रही है या नहीं, बिना duplicates बढ़ाए या unpaid events को count किए।

Step 1: Consent, Data Handling, और Retention तैयार करें

Enhanced Conversions first-party data पर निर्भर करता है, इसलिए build की शुरुआत consent और governance से होनी चाहिए। Google Enhanced Conversions को hashed customer data का उपयोग करके conversion measurement बेहतर बनाने के रूप में बताता है; इससे data को lawful तरीके से collect और process करने की आपकी जिम्मेदारी समाप्त नहीं होती।

केवल वही fields collect करें जिन्हें आप justify कर सकते हैं

Practical affiliate setup आमतौर पर email से शुरू होता है क्योंकि opt-in या checkout पर यह अक्सर उपलब्ध होता है। Phone, name, और postal code जब स्वाभाविक रूप से collect हों तो matching बेहतर कर सकते हैं, लेकिन tracking के लिए ही extra fields न जोड़ें अगर वे friction या compliance risk पैदा करते हों।

Minimal field set का उपयोग करें:

1. Email address.
2. Country code के साथ phone number.
3. First और last name.
4. ZIP या postal code.
5. Country, जहाँ उपलब्ध हो।

हर field के लिए clear source, consent state, और retention rule होना चाहिए। अगर consent missing है, तो conversion internal रूप से फिर भी record की जा सकती है, लेकिन identifier को Enhanced Conversions field के रूप में नहीं भेजना चाहिए।

Retention और access document करें

क्या store किया गया है, कहाँ store किया गया है, किसे access है, और कब delete किया जाता है, यह लिखें। छोटी teams के लिए एक simple data map पर्याप्त है, बशर्ते वह accurate हो और किसी नए offer, landing page, या network integration के live होने पर review किया जाए।

यहीं server-side route मदद करता है। एक documented affiliate tracking and compliance workflow आपको consent state, hashing, payload signing, और deduplication लागू करने के लिए एक ही जगह देता है, बजाय logic को pages और scripts में बिखेरने के।

Step 2: Identifiers को सही तरीके से Normalize और Hash करें

Normalization build का वह हिस्सा है जिसमें silent failure की सबसे ज़्यादा संभावना होती है। अगर एक system spaces, casing, punctuation, या local phone formatting रखता है और दूसरा नहीं, तो दोनों एक ही user का अलग hash बना सकते हैं।

Hashing से पहले normalize करें

Hashing से पहले, consistent rules लागू करें:

• Leading और trailing spaces हटाएँ।
• Email addresses को lowercase करें।
• Phone numbers से spaces और punctuation हटाएँ।
• संभव हो तो phone numbers को country code के साथ रखें।
• First और last name को consistently split करें।
• Postal codes को country के हिसाब से documented format में रखें।

अधिकांश Enhanced Conversions implementations customer identifiers के लिए SHA-256 hashing का उपयोग करते हैं। महत्वपूर्ण बात सिर्फ algorithm नहीं है; यह सुनिश्चित करना है कि वही normalized input हर बार बिल्कुल एक जैसा रहे जब वही identifier फिर से आए।

Affiliate flows के लिए server-side hashing को प्राथमिकता दें

Browser-side hashing pilot के लिए काम कर सकता है, खासकर जब thank-you page तुरंत पूरा data प्राप्त कर ले। Affiliate funnels में अक्सर redirects, pre-sell pages, delayed approvals, और network postbacks होते हैं, इसलिए server-side hashing आमतौर पर audit करना आसान होता है।

Server-side implementation आपको यह log करने देती है कि hash generate हुआ या नहीं, consent मौजूद था या नहीं, और order ID पहले से मौजूद था या नहीं। ये logs तब बहुत उपयोगी होते हैं जब Google Ads conversions affiliate network से कम दिखाता है या कोई network duplicate webhooks भेजता है।

Step 3: Google Ads Conversion Actions Configure करें

ऐसे conversion actions बनाइए जो आपके funnel stages से match करें, बजाय इसके कि हर event को एक generic action में डाल दिया जाए। Mixed events bidding data को समझना कठिन बना देते हैं।

Action names और values को specific रखें

ऐसे names इस्तेमाल करें जो वास्तविक event का वर्णन करें, जैसे Lead Submitted, Purchase Confirmed, या Payout Verified Sale। जब payout या order value ज्ञात हो, तो value और currency भेजें। अगर commission product, tier, या network के अनुसार बदलती है, तो flat value न भेजें जब तक वह value स्पष्ट रूप से estimate के रूप में documented न हो।

Google का Enhanced Conversions documentation और Google Ads Help resources current setup screens, required fields, और account-level settings के लिए आपकी source of truth होने चाहिए। Strategic rule interface बदलने पर भी stable रहती है: हर conversion action को deterministic event name, value rule, और deduplication key चाहिए।

सभी systems में एक ही order ID का उपयोग करें

Google Ads, आपके landing stack, affiliate network, और reporting database में एक ही internal order ID या transaction ID का उपयोग करें। Temporary click ID को order ID का स्थान न लेने दें।

Good deduplication logic तीन सवालों का जवाब देता है:

• क्या यह order ID पहले ही count किया जा चुका है?
• क्या network ने बाद में इसे reverse, refund, या reject किया?
• क्या पहले event के बाद conversion value बदली?

अगर जवाब बदलता है, तो platform-supported method के जरिए उचित adjustment भेजें, reporting से reversals छिपाएँ नहीं। Clean attribution तभी उपयोगी है जब वह financially honest भी रहे।

Step 4: Thank-you Page और Postbacks से Events भेजें

एक durable affiliate setup आमतौर पर page-level और server-side दोनों signals का उपयोग करता है। Page event user action के करीब conversion capture करता है, जबकि network postback यह confirm करता है कि event payable बना या नहीं।

पहले thank-you page validate करें

एक controlled test path से शुरू करें। एक test lead या purchase submit करें, फिर confirm करें कि thank-you page एक बार fire हो, अपेक्षित conversion action शामिल हो, और placeholder identifiers न भेजे।

हर test conversion के लिए यह log करें:

• Timestamp.
• Conversion action name.
• Internal order ID.
• Consent state.
• मौजूद identifier fields.
• Hash generation status.
• Google Ads ingestion status, जब उपलब्ध हो।

अगर logs में missing order IDs, inconsistent hashing, या duplicate thank-you page fires दिखें, तो scale न करें। ऐसे issues volume बढ़ने पर आमतौर पर और महंगे हो जाते हैं।

Network postbacks से enrich करें

Network webhooks को transaction state update करनी चाहिए, न कि अंधाधुंध दूसरी conversion बनानी चाहिए। ClickBank, Digistore24, और समान networks के लिए postback initial event के बाद approval, payout value, refund, chargeback, या cancellation confirm कर सकता है।

एक practical pattern यह है:

1. Page event को pending के रूप में record करें।
2. Webhook को उसी order ID से match करें।
3. Payout status और value update करें।
4. Final confirmed event या adjustment केवल एक बार भेजें।

इससे Google Ads आर्थिक truth के करीब रहता है, जबकि campaign management के लिए timely conversion signals भी सुरक्षित रहते हैं।

Step 5: Bids बदलने से पहले Match Quality validate करें

Rollout को साबित करना चाहिए कि नया signal बड़ा नहीं, बल्कि साफ़ है। अधिक reported conversions तभी मददगार हैं जब वे paid outcomes से align हों।

Controlled comparison चलाएँ

एक stable offer, एक traffic source, और एक learning window चुनें। Original pixel-only या baseline action की तुलना Enhanced Conversions action से करें, और उसी समय creative, offer page, या bid strategy न बदलें।

Low-to-medium volume campaigns के लिए 7-14 day validation window उपयोग करें। High-volume accounts signal तेज़ देख सकते हैं, लेकिन उन्हें भी postback delay और duplicate behavior देखने के लिए पर्याप्त समय चाहिए।

Daily diagnostics checklist बनाएँ

Rollout के दौरान हर दिन ये items review करें:

• Google Ads conversions बनाम network-confirmed conversions.
• Google Ads में match status या diagnostic warnings.
• Hash generation failures.
• Duplicate transaction IDs.
• Unmatched network postbacks.
• Refund और reversal adjustments.
• Lag account करने के बाद CPA और ROAS movement.

एक useful operator target कोई universal match-rate number नहीं है। लक्ष्य यह है कि unexplained mismatch causes कम हों, जबकि payable revenue, order IDs, और conversion values aligned रहें।

Step 6: Measurement Quality को Offer Reality से जोड़ें

Enhanced Conversions measurement सुधारता है। यह यह साबित नहीं करता कि कोई affiliate offer अभी भी fresh, compliant, या profitably scaling है।

Tracking lift और market lift को अलग करें

अगर attribution improve होता है और CPA गिरता हुआ दिखता है, तो देखें कि offer market में भी hold कर रहा है या नहीं। Creative fatigue, नए competitor angles, payout changes, और landing page changes सभी clean tracking को वास्तविक scaling opportunity से बेहतर दिखा सकते हैं।

Daily Intel Service इस दूसरे सवाल में मदद करता है, क्योंकि यह active offer movement, VSL changes, creative shifts, और funnel behavior की निगरानी करता है। इस intelligence को अपनी attribution data के साथ उपयोग करें, उसकी जगह नहीं।

एक अधिक disciplined operating loop के लिए, daily budget बढ़ाने से पहले अपने tracking results की तुलना the Daily Intel methodology से करें। इससे decision measurement quality और current market evidence दोनों पर आधारित रहता है।

कब पूरा server-side pipeline उचित है

मध्यम volume और manageable postback complexity वाले affiliates के लिए Enhanced Conversions अक्सर पर्याप्त होता है। जब spend ज़्यादा हो, कई networks हों, strict consent segmentation हो, refunds हों, upsells हों, या recurring billing हो, तब full server-side conversion pipeline अधिक महत्वपूर्ण हो जाता है।

अगर आपका baseline data साफ़ है, तो overbuild न करें। अगर आपका mismatch persistent और financially material है, तो server-side reconciliation आमतौर पर अगला कदम है।

Implementation Checklist

Setup complete कहने से पहले इस checklist का उपयोग करें:

• Primary conversion event payable या high-confidence outcome को दर्शाता है।
• Identifiers process होने से पहले consent state capture की गई है।
• Email, phone, name, और postal fields consistently normalized हैं।
• जहाँ आवश्यक हो, normalization के बाद SHA-256 hashing लागू की गई है।
• एक transaction ID Google Ads, network postbacks, और आपके ledger में order को follow करती है।
• Duplicate, refund, reversal, और value-adjustment rules documented हैं।
• 7-14 day test नए setup की तुलना baseline से करता है।
• Budget changes तब तक रुकी रहती हैं जब तक match quality और payout reconciliation सहमत न हों।

Daily Intel Service को workflow में तब आना चाहिए जब tracking भरोसेमंद हो जाए: इसका उपयोग यह तय करने के लिए करें कि offer और funnel में अभी भी scale को justify करने के लिए पर्याप्त live momentum है या नहीं।

Frequently Asked Questions

Q: क्या हर affiliate campaign के लिए Google Enhanced Conversions ज़रूरी है?
A: नहीं। यह तब सबसे उपयोगी है जब redirects, cookie loss, iOS traffic, delayed postbacks, या cross-device behavior pixel-only reporting को अविश्वसनीय बना देते हैं। Stable attribution वाले simple funnels को तुरंत इसकी ज़रूरत नहीं हो सकती।

Q: Affiliates को कौन-सा customer data भेजना चाहिए?
A: केवल consented, normalized identifiers भेजें जिन्हें आपका funnel पहले से collect करता है, जैसे email, phone, name, postal code, और country। Raw values आंतरिक रूप से controlled रहनी चाहिए; outgoing Enhanced Conversions fields को Google के required hashing और formatting rules का पालन करना चाहिए।

Q: Hashing browser में होनी चाहिए या server पर?
A: Affiliate campaigns के लिए server-side hashing आमतौर पर बेहतर है क्योंकि इसे audit करना, network postbacks के साथ reconcile करना, और page-level script failures से बचाना आसान है। सीमित pilot के लिए browser-side hashing स्वीकार्य हो सकती है।

Q: Bids बदलने से पहले मुझे कितने समय तक test करना चाहिए?
A: अधिकांश low-to-medium volume campaigns के लिए 7-14 day validation window उपयोग करें। Spend बढ़ाने से पहले match quality, duplicate rates, conversion lag, CPA, और payout-confirmed revenue की तुलना करें।

Q: क्या Enhanced Conversions ClickBank, Digistore24, या अन्य affiliate networks के साथ काम कर सकता है?
A: हाँ, अगर हर network postback उसी internal transaction ID और reconciliation rules पर map होती है। Network को duplicate conversions बनाने के बजाय payout status, value, refund, या rejection state update करनी चाहिए।

Q: क्या बेहतर attribution का मतलब है कि offer scale करने के लिए तैयार है?
A: नहीं। बेहतर attribution आपको अधिक सटीक रूप से बताती है कि क्या हुआ; यह यह साबित नहीं करती कि offer अभी भी competitive है। Budgets बढ़ाने से पहले current creative, funnel, payout, और market signals validate करें।