रेस्टॉरंटसाठी Meta Conversions API एकत्रीकरण: प्रत्यक्ष भेटींविरुद्ध जाहिरातींचे मूल्यमापन

गेस्ट WiFi सह Meta Conversions API समाकलित केल्याने रेस्टॉरंट्सना GDPR मानकांनुसार जाहिरातींच्या खर्चाविरुद्ध ऑफलाइन भेटींचे मोजमाप करण्याची अनुमती मिळते. 80,000+ पेक्षा जास्त ठिकाणी हॅश केलेले SHA-256 लॉगिन रेकॉर्ड पाठवून, ऑपरेटर प्रत्यक्ष भेट देणाऱ्यांची नोंद थेट मोहिमांशी जोडतात, ज्यामुळे खऱ्या जाहिरातींच्या परताव्याचा मागोवा घेण्यासाठी ऑनलाइन बुकिंगच्या पुढे जाता येते.

Meta Conversions API रेस्टॉरंटसाठी काय करते?

Meta आपल्या जाहिरातींचे मूल्यमापन ते पाहू शकत असलेल्या इव्हेंटवरून करते. बहुतांश रेस्टॉरंट्ससाठी, हे इव्हेंट वेबसाइटवरील पिक्सेल इव्हेंट असतात: एक बुकिंग, मेनू पाहणे किंवा व्हाउचर डाउनलोड करणे. ज्या ग्राहकाने तुमची जाहिरात पाहिली, वेबसाइट वगळली आणि दुपारच्या जेवणासाठी थेट रेस्टॉरंटमध्ये आला, तो कधीही दिसत नाही. तरीही ती भेट म्हणजे असा परिणाम आहे ज्यासाठी तुम्ही पैसे दिले होते.

Conversions API (CAPI) हे Meta चे सर्व्हर-टू-सर्व्हर कनेक्शन आहे. ब्राउझरमधील स्क्रिप्टवर अवलंबून राहण्याऐवजी तुमची सिस्टम थेट Meta ला इव्हेंट पाठवते. Meta वेबसाइट, ॲप आणि ऑफलाइन इव्हेंटसाठी याचे दस्तऐवजीकरण करते. ऑफलाइन इव्हेंटमध्ये "physical_store" या ॲक्शन सोर्ससह चिन्हांकित केलेल्या भौतिक स्थानावरील भेटींचा समावेश होतो.

केवळ पिक्सेल-आधारित रिपोर्टिंग रेस्टॉरंटच्या निकालांची नोंद कमी का करते

तुमच्या जाहिराती जे साध्य करतात आणि Ads Manager जे रिपोर्ट करते त्यामध्ये तीन अंतर निर्माण होतात.

• भेट ऑफलाइन होते. Meta Pixel फक्त तुमच्या स्वतःच्या पेजवर, ब्राउझरमध्ये चालतो. थेट येणारा ग्राहक, फोनवरून केलेले बुकिंग किंवा थर्ड-पार्टी प्लॅटफॉर्मवरून केलेल्या बुकिंगचा कोणताही पिक्सेल इव्हेंट राहत नाही.
• ब्राउझर इव्हेंट सोडून देतात. Meta चे स्वतःचे मार्गदर्शन सांगते की Conversions API ब्राउझर लोडिंग एरर, कनेक्टिव्हिटी समस्या आणि ॲड ब्लॉकर्समुळे होणारे डेटा नुकसान कमी करते.
• डिव्हाइस गोपनीयता सेटिंग्ज सिग्नल मर्यादित करतात. iOS 14.5 पासून, Apple ने इतर कंपन्यांच्या ॲप्स आणि वेबसाइट्सवर ॲक्टिव्हिटी डेटा वापरण्यापूर्वी ॲप्सना परवानगी मागणे अनिवार्य केले आहे. अनेक लोक ते नाकारतात, ज्यामुळे पिक्सेल पूर्वी ज्या सिग्नलवर अवलंबून होता ते काढून टाकले जातात.

याची किंमत ही केवळ रिपोर्टिंगमधील अंतरापेक्षा जास्त आहे. Meta ची डिलिव्हरी सिस्टीम त्या लोकांच्या दिशेने अधिक चांगल्या प्रकारे कार्य करते जे त्यांना मिळणारे इव्हेंट तयार करतात. जर ते फक्त ऑनलाइन बुकिंग असतील, तर बजेट ऑनलाइन बुकिंग करणाऱ्या लोकांकडे वळते. थेट येणाऱ्या ग्राहकांनी टेबल भरणाऱ्या मोहिमा महागड्या दिसतात, त्यामुळे त्या थांबवल्या जातात.

जेव्हा भेटी Meta पर्यंत पोहोचतात तेव्हा काय बदलते?

तुम्ही तुमच्या WiFi वर लॉगिन करणाऱ्या प्रत्येक संमती दिलेल्या पाहुण्यासाठी हॅश केलेला ईमेल किंवा फोन नंबर आणि टाइमस्टॅम्पसह एक भेट इव्हेंट पाठवता. Meta शक्य तिथे त्या इव्हेंटचा व्यक्तीच्या Meta खात्याशी मेळ घालते. त्यानंतर ते तुमच्या एट्रिब्यूशन सेटिंगमध्ये त्यांनी पाहिलेल्या किंवा क्लिक केलेल्या कोणत्याही जाहिरातीविरुद्ध भेटीची नोंद करते. तुम्हाला केवळ प्रति बुकिंग खर्च नाही, तर प्रति भेट खर्च (cost per visit) मिळतो.

कठीण भाग API नाही. तर कोणी आणि कधी भेट दिली याचा एक विश्वासार्ह, संमती असलेला रेकॉर्ड ठेवणे हा आहे. Mailchimp, Klaviyo आणि HubSpot सारखे ईमेल प्लॅटफॉर्म तुमच्याकडे आधीपासून असलेल्या सूचीवर मोहिमा पाठवतात. ग्राहक तुमच्या दारातून आत आला याची नोंद ते करत नाहीत. गेस्ट WiFi हे करते: प्रत्येक लॉगिन हा पाहुण्याच्या संमतीच्या पर्यायाशी जोडलेला, टाइमस्टॅम्प असलेला, फर्स्ट-पार्टी भेटीचा रेकॉर्ड असतो. Purple च्या 80,000+ पेक्षा जास्त लाइव्ह ठिकाणी, पाहुण्यांनी 2024 मध्ये 440 दशलक्ष वेळा लॉगिन केले (Purple डेटा). भेट मोजमापासाठी हेच कच्चे साहित्य आहे.

Conversions API सह सुरुवात करण्यापूर्वी तुम्हाला कशाची गरज आहे?

कोणासही कोड लिहिण्यापूर्वी किंवा इंटिग्रेशन कनेक्ट करण्यापूर्वी सात गोष्टी जमा करा.

1. ॲडमिन ॲक्सेससह Meta बिझनेस पोर्टफोलिओ, तसेच तुमचा ॲड्स रिपोर्ट ज्यावर आधारित आहे तो डेटासेट. Meta आता ज्याला पिक्सेल आयडी म्हटले जायचे त्यासाठी "डेटासेट" हा शब्द वापरते.
2. Conversions API ॲक्सेस टोकन, जे त्या डेटासेटसाठी Meta इव्हेंट्स मॅनेजरमध्ये जनरेट केले जाते.
3. सर्व्हर-साइड इव्हेंट्स पाठवण्याचा एक मार्ग. याचा अर्थ तुमचा स्वतःचा डेव्हलपर, Meta पार्टनर इंटिग्रेशन, किंवा Meta कनेक्टर असलेले CRM किंवा कस्टमर डेटा प्लॅटफॉर्म.
4. संमती असलेला भेट डेटा. तुम्हाला ईमेल किंवा फोन, टाइमस्टॅम्प, ठिकाण आणि संमती स्थितीसह गेस्ट WiFi लॉगिन रेकॉर्डची आवश्यकता आहे. Purple Engage प्रत्येक लॉगिनवरून तयार केलेल्या गेस्ट प्रोफाईलच्या स्वरूपात हे ठेवते.
5. कायदेशीर आधार आणि अद्ययावत प्रायव्हसी सूचना. GDPR आर्टिकल 6 अंतर्गत तुम्हाला Meta सोबत डेटा शेअर करण्यासाठी कायदेशीर आधाराची आवश्यकता आहे. ॲड मोजमापासाठी, ती सहसा संमती असते, जी आर्टिकल 7 मधील अटी पूर्ण करणारी असावी.
6. भेट डेटाची एक सामायिक व्याख्या. काय गृहीत धरायचे ते ठरवा: प्रति ठिकाण प्रति दिवस प्रति गेस्ट एक लॉगिन, कर्मचाऱ्यांना वगळून.
7. एक बेसलाईन. प्रत्येक कॅम्पेनचे चार आठवड्यांचे केवळ-पिक्सेल निकाल एक्सपोर्ट करा जेणेकरून तुम्ही आधीच्या आणि नंतरच्या निकालांची तुलना करू शकाल.

पाचव्या मुद्द्यावर, सोशल मीडिया युजर्सच्या टार्गेटिंगवरील युरोपियन डेटा प्रोटेक्शन बोर्डच्या Guidelines 8/2020 वाचा. जाहिरातदार आणि प्लॅटफॉर्म काही प्रक्रिया सामायिकपणे कशी नियंत्रित करू शकतात याचे वर्णन त्यांनी केले आहे. तुम्ही डेटा पाठवता तेव्हा तुमच्या जबाबदाऱ्या काय असतात हे Meta च्या बिझनेस टूल अटींमध्ये देखील स्पष्ट केले आहे. तुमच्या सर्व्हरवरून पहिला इव्हेंट जाण्यापूर्वी तुमच्या डेटा प्रोटेक्शन प्रमुखाने दोन्ही गोष्टींना मंजुरी दिली पाहिजे.

तुम्ही गेस्ट WiFi भेट डेटा Conversions API शी कसा कनेक्ट करता?

ही सेटअप प्रक्रिया सहा टप्प्यांत चालते. Meta चे डेव्हलपर दस्तऐवज तांत्रिक तपशील कव्हर करतात; हा विभाग तुमच्या निर्णयांना कव्हर करतो.

1. WiFi लॉगिनवर संमती घ्या

तुमचे WiFi लॉगिन पेज हेच संमतीची सुरुवात आहे. ईमेल मार्केटिंग संमतीपेक्षा जाहिरात मोजमाप संमती स्वतंत्रपणे मागा. GDPR मधील Recital 32 स्पष्टपणे सांगते की शांतता आणि आधीच टिक केलेले बॉक्स संमती मानले जात नाहीत. Purple या कारणासाठी जाणीवपूर्वक निवडीच्या ऑप्ट-इन्सचा वापर करते: पाहुणा सक्रियपणे निवड करतो आणि ती निवड प्रोफाईलसह स्टोअर केली जाते.

सोप्या भाषेत मजकूर लिहा. उदाहरणार्थ: "तुमच्या ईमेलची कोडेड आवृत्ती आम्हास Meta सोबत शेअर करू द्या जेणेकरून आमच्या जाहिरातींमुळे तुम्ही येथे आलात की नाही हे आम्ही पाहू शकू." धोरणाच्या लिंकपेक्षा एक स्पष्ट वाक्य अधिक ऑप्ट-इन्स मिळवून देते.

2. भेट इव्हेंट परिभाषित करा

Meta च्या मानक इव्हेंट्समध्ये रेस्टॉरंट भेटीचा समावेश नाही, त्यामुळे बहुतेक ठिकाणे एक कस्टम इव्हेंट तयार करतात. याला "VenueVisit" असे काहीतरी स्पष्ट नाव द्या. पाहुण्याने दिवसातून तीन वेळा लॉगिन केले तरीही प्रति पाहुणा, प्रति ठिकाण, प्रति दिवस एक इव्हेंट पाठवा. कर्मचाऱ्यांची डिव्हाइसेस आणि आठवड्यातून चार पेक्षा जास्त दिवस लॉगिन करणाऱ्या कोणत्याही पाहुण्याला वगळा, जे सहसा कर्मचारी असल्याचे दर्शवते.

3. मॅचिंग डेटा तयार करा आणि हॅश करा

Meta ला पाठवण्यापूर्वी ईमेल आणि फोन सारखे वैयक्तिक आयडेंटिफायर्स SHA-256 सह नॉर्मलाइझ आणि हॅश करणे आवश्यक आहे. नॉर्मलाइझ करणे म्हणजे जागा काढणे, ईमेल लहान अक्षरात करणे आणि फोन नंबरमध्ये कंट्री कोड जोडणे. खराब नॉर्मलायझेशन हे मॅचेस अयशस्वी होण्याचे सर्वात सामान्य कारण आहे.

प्रत्येक इव्हेंटसाठी इव्हेंटची वेळ, अॅक्शन सोर्स "physical_store" आणि एक युनिक इव्हेंट ID असणे आवश्यक आहे. फक्त Meta द्वारे सूचीबद्ध केलेले पॅरामीटर्स पाठवा. MAC अड्रेसेस सारखे नेटवर्क आयडेंटिफायर्स यामध्ये येत नाहीत आणि ते तुमच्या सिस्टममधून कधीही बाहेर पडू नयेत.

4. दररोजच्या बॅचमध्ये इव्हेंट्स पाठवा

Meta त्याच्या डॉक्युमेंट केलेल्या वेळेपेक्षा जुने इव्हेंट्स नाकारते, त्यामुळे त्यांना एका आठवड्यासाठी रांगेत ठेवू नका. किमान एका दैनंदिन बॅचचे शेड्युल करा आणि ते तयार करताना Meta च्या डॉक्युमेंटेशनमधील सध्याची वेळ मर्यादा तपासा. दैनंदिन पाठवणीमुळे Ads Manager साप्ताहिक मोहिमेच्या समीक्षेसाठी रिअल टाइमच्या पुरेसे जवळ राहते.

5. लाइव्ह होण्यापूर्वी चाचणी करा

Events Manager मधील Meta चे Test Events टूल, जेव्हा तुम्ही टेस्ट कोडसह इव्हेंट्स पाठवता तेव्हा ते आल्यावर दाखवते. आधी काही माहित असलेल्या भेटी पाठवा. लाइव्ह सेंडवर स्विच करण्यापूर्वी इव्हेंटचे नाव, वेळ आणि अॅक्शन सोर्स योग्यरित्या वाचले जात असल्याची खात्री करा.

6. कस्टम कन्व्हर्जन तयार करा आणि रिपोर्टिंगमध्ये जोडा

तुमच्या व्हिजिट इव्हेंटमधून कस्टम कन्व्हर्जन तयार करा, नंतर ते Ads Manager मध्ये एक कॉलम म्हणून जोडा. आता तुम्ही प्रत्येक मोहिमेनुसार बुकिंगच्या खर्चासोबत प्रति भेट होणारा खर्च वाचू शकता.

तुम्ही Meta ला काय आणि कधी पाठवले पाहिजे?

मर्यादित स्वरूपात सुरुवात करा. एक स्पष्ट व्हिजिट इव्हेंट तुम्हाला पाच गोंधळात टाकणाऱ्या इव्हेंट्सपेक्षा जास्त माहिती देतो. जेव्हा पहिला इव्हेंट योग्यरित्या मॅच होत असेल आणि तुमच्या टीमचा या आकड्यांवर विश्वास असेल तेव्हाच नवीन इव्हेंट्स जोडा.

इव्हेंट	डेटा कोठून येतो	मॅचिंग डेटा पाठवला	कधी पाठवायचे	हे तुम्हाला काय सांगते
VenueVisit (कस्टम)	गेस्ट WiFi लॉगिन, फक्त सहमती दिलेले पाहुणे	हॅश केलेला ईमेल, हॅश केलेला फोन, इव्हेंटची वेळ, ठिकाण	दैनंदिन बॅच	मोहिमेनुसार प्रति भेट खर्च
ReturnVisit (कस्टम)	30 दिवसांच्या आत दुसरे WiFi लॉगिन	हॅश केलेला ईमेल, हॅश केलेला फोन, इव्हेंटची वेळ, ठिकाण	दैनंदिन बॅच	जाहिराती लोकांना फक्त एकदाच नाही तर पुन्हा परत आणतात का
Purchase (मानक)	पाहुण्याशी लिंक केलेली टिल किंवा EPOS नोंद	हॅश केलेला ईमेल, मूल्य, चलन, इव्हेंटची वेळ	दैनंदिन बॅच	जाहिरातींमुळे मिळालेला महसूल
Schedule (मानक)	ऑनलाइन बुकिंग सिस्टम	हॅश केलेला ईमेल, इव्हेंटची वेळ, पिक्सेलसह शेअर केलेला इव्हेंट ID	एका तासाच्या आत	ब्राउझर डेटा गमावण्यापासून रिकव्हर केलेली बुकिंग्स

प्रत्येक पंक्तीसाठी दोन नियम लागू होतात. पहिले, फक्त अशाच पाहुण्यांची माहिती पाठवा ज्यांनी जाहिरात मोजणीसाठी सहमती दिली आहे आणि त्यांनी ती काढून घेताच डेटा पाठवणे थांबवा. दुसरे, जेव्हा पिक्सेल आणि सर्व्हर दोन्ही एकाच वेब इव्हेंटची नोंद करतात, तेव्हा तेच इव्हेंट नाव आणि इव्हेंट ID वापरा. Meta डुप्लिकेशन टाळण्यासाठी ती जोडी वापरते, जेणेकरून बुकिंग दोनदा मोजले जात नाही.

CRM डायरेक्टरसाठी रिटर्न व्हिजिट इव्हेंट सर्वात महत्त्वाचा असतो. जाहिरातीवरून पहिली भेट उपयुक्त ठरते. 30 दिवसांच्या आत दुसरी भेट दर्शवते की जाहिरातीने एक नाते सुरू केले आहे जे तुमचा ईमेल आणि मेसेजिंग प्रोग्राम पुढे नेऊ शकतो. फॉलो-अप चॅनेलसाठी, WhatsApp vs SMS for restaurant marketing: cost and reach compared मध्ये खर्चाची तुलना करा.

तुमच्या रेस्टॉरंटसाठी कोणती मोजमाप पद्धत योग्य आहे?

पेड सोशल मोजण्याचा एकमेव मार्ग सर्व्हर-साइड व्हिजिट इव्हेंट्स हा नाही. योग्य निवड तुमचे ग्राहक कुठे कन्व्हर्ट होतात आणि तुमच्याकडे कोणता डेटा आहे यावर अवलंबून असते.

पद्धत	ही काय पाहते	वॉक-इन भेटी मोजते	तुम्हाला आवश्यक डेटा	सेटअपचे प्रयत्न	कोणासाठी योग्य
फक्त Meta Pixel	ब्राउझरमधील वेबसाइट इव्हेंट्स	नाही	तुमच्या बुकिंग आणि मेनू पेजवर Pixel	कमी: साइटवर एक टॅग
ज्यादातर कव्हर ऑनलाइन बुक करणारी ठिकाणे
वेब इव्हेंट्ससाठी Pixel आणि CAPI	ब्राउझर लॉस रिकव्हर केलेल्या वेबसाइट इव्हेंट्स	नाही	Pixel, सर्व्हर ॲक्सेस, शेअर केलेले इव्हेंट IDs	मध्यम: पार्टनर इंटिग्रेशन किंवा डेव्हलपर	उच्च ऑनलाइन बुकिंग प्रमाण असलेले गट
गेस्ट WiFi व्हिजिट इव्हेंट्ससह CAPI	वेब इव्हेंट्ससह संमती दिलेल्या इन-वेन्यू भेटी	होय, संमती दिलेल्या WiFi पाहुण्यांसाठी	ईमेल किंवा फोनसह संमती दिलेल्या लॉगिन नोंदी	मध्यम ते जास्त: संमती पुनरावलोकन, हॅशिंग, दैनंदिन पाठवणे	रेस्टॉरंट्स, बार आणि मजबूत वॉक-इन व्यापार असलेली हॉटेल्स
Meta Conversion Lift अभ्यास	चाचणी आणि नियंत्रण गटांद्वारे जाहिरातींमुळे झालेल्या वाढीव भेटी	होय, तुम्ही पाठवलेल्या व्हिजिट इव्हेंट्सचा वापर करून	व्हिजिट इव्हेंट्ससह चाचणीसाठी पुरेसे बजेट आणि व्हॉल्यूम	जास्त: अनेक आठवड्यांचे नियोजित चाचणी	पेड सोशल खरोखर फायदेशीर आहे का हे तपासणारे गट

निर्णय घेण्यासाठी या तक्त्याचा मार्ग म्हणून वापर करा. जर तुमचे निम्म्यापेक्षा कमी कव्हर्स ऑनलाइन बुक होत असतील, तर pixel रिपोर्टिंग तुमच्या बहुतांश निकालांना मुकते, त्यामुळे व्हिजिट इव्हेंट्स आधी येतात. जर तुम्ही आधीच व्हिजिट इव्हेंट्स पाठवत असाल आणि तुमच्या वित्त टीमला अद्याप पेड सोशलबद्दल शंका असेल, तर lift study चालवा. ॲट्रिब्यूशन तुम्हाला सांगते की जाहिरातीनंतर कोणी भेट दिली. Lift तुम्हाला सांगते की जाहिरातीमुळे कोणी भेट दिली.

दोन सराव केलेली उदाहरणे

खाली दिलेले आकडे पद्धत दाखवण्यासाठी दिलेले स्पष्टीकरणात्मक गणित आहेत. ते कोणत्याही नामांकित ठिकाणाचे रिपोर्ट केलेले निकाल नाहीत.

उदाहरण 1: दुपारच्या जेवणाची ऑफर चालवणारा 12-साइट कॅज्युअल डायनिंग ग्रुप

परिस्थिती. या ग्रुपने Instagram आणि Facebook वर आठवड्याच्या दिवसातील लंच मेनूचा प्रचार करण्यासाठी चार आठवड्यांत £6,000 खर्च केले. Ads Manager ने 40 ऑनलाइन बुकिंग आणि प्रति बुकिंग £150 खर्च रिपोर्ट केला. फायनान्स डायरेक्टरने मोहीम थांबवण्यास सांगितले.

काय केले गेले. मार्केटिंग टीमने WiFi लॉगिन पेजवर एक वेगळा ॲड मेजरमेंट ऑप्ट-इन जोडला. त्यानंतर संमती दिलेल्या पाहुण्यांसाठी रोजचा VenueVisit इव्हेंट पाठवला आणि कस्टम कन्वर्जनभोवती रिपोर्टिंग पुन्हा तयार केले. पुढील चार आठवड्यांची मोहीम त्याच बजेट आणि क्रिएटिव्हसह चालवली गेली.

निकाल. या ग्रुपने 1,900 संमती दिलेले लंचटाईम व्हिजिट इव्हेंट्स पाठवले. Meta ने सात दिवसांच्या क्लिक आणि एका दिवसाच्या व्ह्यू विंडोमध्ये त्यापैकी 310 चे श्रेय मोहिमेला दिले. केवळ pixel डेटावरील प्रति बुकिंग £150 च्या तुलनेत प्रति ॲट्रिब्युटेड व्हिजिट खर्च £19.35 वर आला. मोहीम सुरूच राहिली. त्यानंतर CRM टीमने ReturnVisit इव्हेंटचा वापर करून पाहिले की त्यापैकी 70 पाहुणे 30 दिवसांच्या आत परत आले.

उदाहरण 2: सार्वजनिक रेस्टॉरंट आणि बार असलेले 150 खोल्यांचे हॉटेल

परिस्थिती. हॉटेलने स्थानिक डायनर्ससाठी (रहिवाशांसाठी नाही) आपल्या रेस्टॉरंट आणि बारसाठी Meta जाहिराती चालवल्या. बुकिंगसाठी pixel आणि सर्व्हर इव्हेंट्स आधीच चालवले जात होते, परंतु रिपोर्ट केलेले निकाल एका रात्रीत दुप्पट झाले होते.

काय केले गेले. टीमला आढळले की तिचे बुकिंग इंजिन आणि सर्व्हर इंटिग्रेशन दोन्ही वेगवेगळ्या इव्हेंट ID सह शेड्यूल इव्हेंट पाठवत होते. Meta त्यांची डुप्लिकेट प्रत हटवू (deduplicate) शकले नाही. टीमने इव्हेंट ID एकत्रित केले, नंतर रूम-लिंक केलेल्या प्रोफाईलविरुद्ध लॉगिन फिल्टर करून हॉटेल रहिवाशांना VenueVisit इव्हेंटमधून वगळले.

निकाल. रिपोर्ट केलेल्या बुकिंगची संख्या पुढील महिन्यात 220 वरून 112 वर आली, जी बुकिंग सिस्टमच्या स्वतःच्या मोजणीशी 3% च्या आत जुळत होती. भेट इव्हेंटमध्ये आता फक्त गैर-रहिवासी जेवणाऱ्यांची मोजणी केली गेली, महिन्यात 640. टीम अखेर रहिवासी आणि डुप्लिकेटच्या मिश्रणाऐवजी स्थानिक व्यापाराविरुद्ध रेस्टॉरंट खर्चाची तुलना करू शकली.

Conversions API कार्य करत आहे हे तुम्हाला कसे समजेल?

पहिल्या महिन्यात या क्रमाने पाच सिग्नल तपासा.

मिळालेले इव्हेंट पाठवलेल्या इव्हेंटशी जुळतात

तुमच्या संमती दिलेल्या दैनंदिन भेटींची संख्या Meta ने Events Manager मध्ये प्राप्त झाल्याचे रिपोर्ट केलेल्या इव्हेंटशी जुळली पाहिजे. 5% पेक्षा जास्त फरक असणे म्हणजे पाठवण्यात अपयश, नाकारलेले इव्हेंट किंवा वेळेच्या समस्या दर्शवते.

Event Match Quality सुधारत आहे

Meta प्रत्येक सर्व्हर इव्हेंटला त्याचा मॅचिंग डेटा लोकांना किती चांगल्या प्रकारे ओळखतो यासाठी 10 पैकी स्कोअर देते. ईमेल सोबत हॅश केलेला फोन नंबर जोडल्याने सहसा स्कोअर वाढतो. पहिल्या दिवसाच्या आकड्याऐवजी दर आठवड्याला ट्रेंड पहा.

डीड्युप्लिकेशन स्वच्छ आहे

तुम्ही लाईव्ह केलेल्या दिवशी पिक्सेल आणि सर्व्हर निकाल दोन्ही वेगाने वाढले असल्यास, इव्हेंट बहुधा दोनदा मोजले जातात. दोन्ही स्त्रोतांकडून शेअर केलेल्या इव्हेंटमध्ये समान नाव आणि इव्हेंट ID आहे का ते तपासा.

प्रति भेट खर्च स्थिर आहे

दोन किंवा तीन आठवड्यांनंतर, प्रति ॲट्रिब्यूट केलेल्या भेटीचा खर्च प्रत्येक मोहिमेसाठी सातत्यपूर्ण श्रेणीत स्थिर झाला पाहिजे. मोठे बदल हे दर्शवतात की बॅचेस उशिरा किंवा अनियमितपणे पोहोचत आहेत.

निकाल होल्डआउटविरुद्ध टिकून राहतात

ॲट्रिब्यूशन जाहिरातीचे श्रेय ती पाहणाऱ्या आणि नंतर भेट देणाऱ्या प्रत्येकाला देते, ज्यामध्ये नेहमी येणारे लोक देखील समाविष्ट आहेत जे तरीही आले असते. एक साधी चाचणी घ्या: दोन आठवड्यांसाठी एका तुल्यबल ठिकाणासाठी जाहिराती थांबवा आणि WiFi भेट संख्यांची तुलना करा. अचूक उत्तरासाठी, Meta ची Conversion Lift स्टडी वापरा.

काय चुकीचे होते आणि तुम्ही ते कसे टाळू शकता?

बहुतेक अपयश या प्रक्रिया अपयश असतात, कोड अपयश नाहीत. येथे सहा गोष्टी आहेत ज्यामुळे रेस्टॉरंट ग्रुपचा सर्वाधिक वेळ जातो.

• वैध संमतीशिवाय डेटा पाठवणे. "मार्केटिंग" साठी एक बंडल केलेला संमती बॉक्स जाहिरात मोजमापासाठी GDPR कलम 7 अंतर्गत टिकणार नाही. ऑप्ट-इन्स वेगळे करा आणि प्रत्येक निवड तिच्या टाइमस्टॅम्पसह स्टोअर करा.
• त्याच इव्हेंटची दोनदा मोजणी करणे. मॅचिंग इव्हेंट ID नसलेले पिक्सेल आणि सर्व्हर इव्हेंट तुम्ही रिपोर्ट करत असलेला प्रत्येक आकडा वाढवून दाखवतात. फायनान्स टीमला निकाल दाखवण्यापूर्वी डीड्युप्लिकेशन दुरुस्त करा.
• बॅचेस जुने होऊ देणे. Meta च्या वेळेच्या मर्यादेत रांगेत असलेले इव्हेंट रिपोर्टमध्ये न दिसता नाकारले जातात. दैनिक पाठवणे स्वयंचलित करा आणि ते अयशस्वी झाल्यास कोणालातरी अलर्ट करा.
• कर्मचारी आणि रहिवाशांची जेवणारे म्हणून मोजणी करणे. कर्मचारी प्रत्येक शिफ्टमध्ये लॉगिन करतात आणि हॉटेल रहिवासी दररोज लॉगिन करतात. दोन्ही फिल्टर करा, नाहीतर तुमचा प्रति भेट खर्च आहे त्यापेक्षा चांगला दिसेल.
• प्रत्येक लॉगिनला भेट मानणे. दुपारच्या जेवणानंतर पुन्हा कनेक्ट होणारा पाहुणा अजूनही एकच भेट असतो. प्रति पाहुणा, प्रति ठिकाण, प्रति दिन एक इव्हेंट पाठवा.
• अॅट्रिब्यूशनची कारणाशी गल्लत करणे. तुमची जाहिरात पाहिलेल्या एखाद्या निष्ठावंत नियमित ग्राहकाची नोंद जाहिरातीमुळे झालेल्या भेटीमध्ये केली जाईल. मोठे बजेट हलवण्यापूर्वी होल्डआउट्स किंवा लिफ्ट स्टडीजचा वापर करा.

आणखी एक अपयश संपूर्णपणे Meta च्या बाहेर आहे: संमती मिळालेली एक तोकडी यादी. भेट मोजणी फक्त त्या पाहुण्यांसाठीच कार्य करते ज्यांनी ऑप्ट-इन केले आहे. WiFi लॉगिनवरील ऑप्ट-इन दराला पेड मीडिया मेट्रिक म्हणून घ्या, कारण ते तुम्ही काय मोजू शकता याची कमाल मर्यादा निश्चित करते.

वारंवार विचारले जाणारे प्रश्न

Meta Conversions API हे Meta Pixel ची जागा घेते का?

नाही, Meta pixel ऐवजी नाही तर त्याच्यासोबत Conversions API चालवण्याची शिफारस करते. Pixel प्रत्यक्ष वेळेत ब्राउझर इव्हेंट कॅप्चर करतो, तर सर्व्हर कनेक्शन ब्राउझर गमावलेले इव्हेंट पुनर्प्राप्त करतो आणि ऑफलाइन भेटी जोडतो. जेव्हा दोन्ही एकाच वेब इव्हेंटची नोंद करतात, तेव्हा समान इव्हेंट नाव आणि इव्हेंट ID पाठवा. Meta नंतर ते एकदाच मोजते. थेट येणाऱ्या भेटींसाठी, फक्त सर्व्हर कनेक्शन लागू होते, कारण डुप्लिकेट करण्यासाठी कोणताही ब्राउझर इव्हेंट नसतो.

पाहुण्यांचा WiFi डेटा Meta सोबत शेअर करणे GDPR शी सुसंगत आहे का?

होय, तुमच्याकडे कायदेशीर आधार असल्यास, जो जाहिरात मोजणीसाठी सहसा स्पष्ट संमती असतो. GDPR आर्टिकल 7 अटी निश्चित करते आणि रिसायटल 32 आधीच टिक केलेल्या बॉक्सचा पर्याय नाकारते. पाहुण्यांना सोप्या शब्दांत सांगा की त्यांच्या ईमेलची कोड केलेली आवृत्ती जाहिराती मोजण्यासाठी Meta कडे जाते. Meta च्या आवश्यकतेनुसार SHA-256 सह हॅश आयडेंटिफायर्स वापरा. एखाद्या पाहुण्याने संमती काढून घेतल्यास त्वरित पाठवणे थांबवा. तुमच्या डेटा संरक्षण प्रमुखांना युरोपियन डेटा प्रोटेक्शन बोर्डच्या मार्गदर्शक तत्त्वे 8/2020 चे पुनरावलोकन करण्यास सांगा.

हे आमच्याकडे आधीपासून असलेल्या WiFi हार्डवेअरसोबत काम करेल का?

होय, Purple हे हार्डवेअर-अॅग्नोस्टिक आहे आणि तुमच्या सध्याच्या ॲक्सेस पॉईंट्सवर क्लाउड ओव्हरले म्हणून चालते. हे Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme आणि Fortinet सोबत काम करते. संमती दिलेल्या लॉगिन नोंदी कॅप्चर करण्यासाठी तुम्हाला हार्डवेअर बदलण्याची गरज नाही. भेटीचा डेटा नंतर Conversions API साठी तयार होण्यास सज्ज असलेले पाहुण्यांचे प्रोफाइल म्हणून Purple Engage मध्ये येतो.

हे Mailchimp, Klaviyo किंवा HubSpot वापरण्यापेक्षा कसे वेगळे आहे?

फरक हा आहे की भेटीचा डेटा कोठून येतो. Mailchimp, Klaviyo आणि HubSpot तुमच्याकडे आधीपासून असलेल्या यादीला मोहिमा पाठवतात. एखादा ग्राहक तुमच्या रेस्टॉरंटमध्ये प्रत्यक्ष चालत आला आहे याची नोंद ते करत नाहीत. Purple Engage ही यादी पाहुण्यांच्या WiFi लॉगिनवरून तयार करते, ज्यातील प्रत्येक टाइमस्टॅम्प केलेली, संमती असलेली, फर्स्ट-पार्टी भेटीची नोंद असते. ही नोंद अशी गोष्ट आहे जी Conversions API कनेक्शनला वेब मोजणीवरून भेट मोजणीमध्ये रूपांतरित करते.

Conversions API सेट अप करण्यासाठी आम्हाला डेव्हलपरची गरज आहे का?

सहसा होय, भेटीच्या इव्हेंटसाठी, जरी काम कमी असले तरीही. वेबसाइट इव्हेंट अनेकदा कमी कोडसह Meta पार्टनर इंटिग्रेशनद्वारे कनेक्ट होऊ शकतात. भेटीच्या इव्हेंटसाठी एका शेड्यूल केलेल्या कामाची आवश्यकता असते जे संमती असलेल्या लॉगिन नोंदी वाचते, आयडेंटिफायर्स नॉर्मलाइज आणि हॅश करते आणि दैनिक बॅच पाठवते. डेव्हलपर, एजन्सी किंवा Meta कनेक्टर असलेले CRM हे तयार करू शकते. बिल्डसोबत संमतीचे शब्द आणि डेटा संरक्षण पुनरावलोकनासाठी वेळ द्या.

भेटी आणि Meta खात्यांमध्ये आम्ही कोणत्या मॅच रेटची अपेक्षा करावी?

Meta तुम्ही पाठवलेल्या भेटींपेक्षा कमी भेटी मॅच करेल अशी अपेक्षा ठेवा. Meta फक्त अशाच लोकांची जुळवणी करू शकते ज्यांचे त्याच ईमेल किंवा फोन नंबरवर Meta खाते आहे. तुमच्याकडे उपलब्ध असल्यास हॅश केलेला ईमेल आणि हॅश केलेला फोन नंबर दोन्ही पाठवा आणि प्रत्येक काळजीपूर्वक नॉर्मलाइज करा. त्यानंतर Events Manager मध्ये Event Match Quality स्कोर पहा. पहिल्या महिन्यात वाढणारा स्कोर दर्शवतो की तुमचा मॅचिंग डेटा सुधारत आहे.

Ads Manager मध्ये भेटींचे परिणाम किती लवकर दिसतील?

Meta ला व्हिजिट इव्हेंट्स प्राप्त होताच ते Events Manager मध्ये दिसतात आणि Test Events ते जसे येतात तसे दाखवतात. प्रत्येक मोहिमेची एट्रिब्यूशन विंडो सुरू झाल्यावर Ads Manager मध्ये एट्रिब्युट केलेले परिणाम तयार होतात. सात दिवसांच्या क्लिक विंडोसह, प्रति भेट खर्चाचा अंदाज लावण्यापूर्वी मोहिमेला किमान एक पूर्ण आठवडा द्या. दररोज दोन ते चार आठवडे पाठवल्याने बजेटच्या निर्णयांसाठी एक विश्वासार्ह दृष्टीकोन मिळतो.