Skip to content

नए साइनअप फर्स्ट वैल्यू तक पहुँचने से पहले कहाँ अटकते हैं?

साइनअप से onboarding होते हुए फर्स्ट वैल्यू तक की यात्रा को फिर से बनाएं, उस चरण का पता लगाएं जो सबसे अधिक अकाउंट खोता है, और उन सुधारों को रैंक करें जो सबसे अधिक राजस्व वापस जीतते हैं। Querri में Amplitude, HubSpot और Salesforce के साथ बनाया गया।

Querri खोलें

आपको क्या चाहिए होगा

Querri (निःशुल्क परीक्षण) सिस्टम के बीच डेटा जोड़ने, फर्स्ट वैल्यू परिभाषित करने, और फ़नल बनाने के लिए

Amplitude, HubSpot और Salesforce एक्सपोर्ट (उत्पाद events, contact lifecycle और स्रोत, साथ ही रूपांतरित-अकाउंट सूची)

एक साझा key जो सिस्टम के बीच रिकॉर्ड को पंक्तिबद्ध करती है: एक आंतरिक अकाउंट ID (सर्वोत्तम), जिसमें email और company domain विकल्प के रूप में हों

निःशुल्क संसाधन

अपना निःशुल्क परीक्षण यहाँ शुरू करें →

नमूना डेटा सेट

सिंथेटिक डेमो डेटासेट, वास्तविक ग्राहक डेटा नहीं। डाउनलोड करने और एक्सप्लोर करने के लिए सुरक्षित। साथ चलें और आपको वही संख्याएँ मिलेंगी जो आप नीचे देखते हैं।

मदद चाहिए?

यदि आपके कोई सवाल हैं, तो आप डेमो का अनुरोध कर सकते हैं या हमारी टीम को ईमेल कर सकते हैं।

शुरू करने से पहले

अधिकांश onboarding रिपोर्ट एक साइनअप गिनती पर रुक जाती हैं। वे आपको बताती हैं कि कितने लोगों ने शुरुआत की, लेकिन यह नहीं कि वे लोग कहाँ चुपचाप वैल्यू पाने से पहले ही अटक जाते हैं। इसलिए टीमें फ़नल के शीर्ष में साइनअप डालती रहती हैं जबकि वही टूटा हुआ चरण बीच से अकाउंट लीक करता रहता है।

तो नए साइनअप वास्तव में कहाँ अटकते हैं? यह playbook पूरी यात्रा (साइनअप, onboarding क्रियाएँ, फर्स्ट वैल्यू, अंतिम रूपांतरण) को तीन सिस्टम को एक अकाउंट-स्तरीय दृश्य में जोड़कर फिर से बनाता है: व्यवहार के लिए Amplitude, acquisition स्रोत के लिए HubSpot, और उन अकाउंट के लिए Salesforce जो अंततः ग्राहक बने। आप सबसे बड़ा अटकाव बिंदु पाएंगे, देखेंगे कि यह किसे सबसे अधिक नुकसान पहुँचाता है, और सुधारों को खोए गए अकाउंट के अनुसार रैंक करेंगे।

यह कैसे काम करता है:

  • Amplitude event स्ट्रीम, HubSpot contact lifecycle डेटा, और Salesforce रूपांतरित-अकाउंट सूची अपलोड करें
  • फर्स्ट वैल्यू को स्पष्ट रूप से परिभाषित करें, फिर हर अकाउंट का साइनअप-से-फर्स्ट-वैल्यू फ़नल फिर से बनाएं
  • उस चरण का पता लगाएं जो सबसे अधिक अकाउंट खोता है, फिर उस drop-off को acquisition स्रोत के अनुसार विभाजित करें
  • रूपांतरित हुए अकाउंट बनाम ठंडे पड़ गए अकाउंट के लिए time-to-first-value की तुलना करें
  • ठीक करने के लिए onboarding चरणों की एक प्राथमिकता-सूची तैयार करें, जो हर एक द्वारा खोए गए अकाउंट के अनुसार रैंक की गई हो

चरणों का पालन करें

Querri खोलें →
1 चरण 1:

Amplitude, HubSpot और Salesforce अपलोड करें

तीनों सिस्टम से एक्सपोर्ट अपलोड करें, या उन्हें सीधे कनेक्ट करें। Amplitude आपको व्यवहार देता है: हर नए साइनअप के लिए event स्ट्रीम, user और अकाउंट ID, event नाम, और event समय के साथ। HubSpot acquisition पक्ष प्रदान करता है, इसलिए contacts को उनके मूल स्रोत, campaign, और lifecycle stage के साथ लाएँ। Salesforce परिणाम है, इसलिए रूपांतरित-अकाउंट सूची को company domain और close date के साथ लाएँ। Querri हर फ़ाइल का प्रोफ़ाइल बनाता है और उसे विश्लेषण के लिए तैयार करता है।

सुझाव: कम से कम 12 महीने के Amplitude events एक्सपोर्ट करें ताकि धीरे सक्रिय होने वाले अकाउंट कट न जाएँ, और हर रिकॉर्ड पर email और company domain शामिल करें। वही फ़ील्ड Querri को तीनों सिस्टम में एक ही अकाउंट को एक साथ जोड़ने देते हैं।

2 चरण 2:

फर्स्ट वैल्यू परिभाषित करें और फ़नल बनाएं

फर्स्ट वैल्यू वह पहला क्षण है जब कोई अकाउंट वास्तव में वह लाभ प्राप्त करता है जिसके लिए उसने साइन अप किया था। इसे स्पष्ट रूप से घोषित करें, फिर Querri से हर अकाउंट का साइनअप से उस क्षण तक का पथ फिर से बनाने को कहें:

Prompt

"फर्स्ट वैल्यू को first_analysis_completed event के रूप में परिभाषित करें। नए साइनअप के cohort के लिए, account_created से email_verified, workspace_created, data_source_connected, import_completed, first_analysis_started होते हुए first_analysis_completed तक onboarding फ़नल बनाएं। हर stage तक पहुँचने वाले अकाउंट और उनके बीच drop-off की गिनती करें।"

परिभाषा पर ध्यान दें। फर्स्ट वैल्यू first_analysis_completed है, एक पूर्ण और उपयोगी परिणाम, न कि केवल एक फ़ाइल अपलोड करना या सेटअप पूरा करना। 2,400 नए साइनअप में से, 1,149 इस तक पहुँचते हैं। यह 47.9% की activation rate है, और अब आप ठीक-ठीक देख सकते हैं कि अन्य 1,251 कहाँ बाहर हो जाते हैं।

फर्स्ट वैल्यू परिभाषित करें और फ़नल बनाएं
3 चरण 3:

drop-off का पता लगाएं और इसे स्रोत के अनुसार विभाजित करें

एक चरण किसी भी अन्य से कहीं अधिक अकाउंट खोता है। इसे खोजें, फिर Querri से उस अटकाव को हर अकाउंट के HubSpot acquisition स्रोत के अनुसार विभाजित करने को कहें:

Prompt

"सबसे बड़ी drop-off वाले फ़नल चरण की पहचान करें। फिर साइनअप को उनके HubSpot मूल स्रोत से जोड़ें और, हर स्रोत के लिए, साइनअप, फर्स्ट वैल्यू तक पहुँचने वाली संख्या, फर्स्ट-वैल्यू rate, और उन अकाउंट का हिस्सा दिखाएं जो एक डेटा स्रोत कनेक्ट करते हैं लेकिन अपना पहला import कभी पूरा नहीं करते।"

सबसे बड़ा अटकाव एक डेटा स्रोत कनेक्ट करने और पहला import पूरा करने के बीच है। 563 अकाउंट, जो इतनी दूर पहुँचते हैं उनका 30%, कभी इसे पार नहीं करते। यह अगले चार चरणों के संयुक्त से अधिक है। और यह एक समान भी नहीं है। Paid Search सबसे अधिक साइनअप लाता है लेकिन लगभग आधे समय import पर अटक जाता है, जबकि Referral और Partner साइनअप आसानी से पार हो जाते हैं।

drop-off का पता लगाएं और इसे स्रोत के अनुसार विभाजित करें
4 चरण 4:

time-to-first-value की तुलना करें: रूपांतरित बनाम ठंडा

अब व्यावसायिक परिणाम लाएँ। Querri से साइनअप को Salesforce रूपांतरित-अकाउंट सूची से मिलाने और तुलना करने को कहें कि दोनों समूह फर्स्ट वैल्यू से कैसे गुज़रते हैं:

Prompt

"अकाउंट को company domain पर Salesforce रूपांतरित-अकाउंट सूची से मिलाएं। रूपांतरित अकाउंट की तुलना उन अकाउंट से करें जो ठंडे पड़ गए, इन पर: फर्स्ट वैल्यू तक पहुँचने वाला हिस्सा, वह हिस्सा जो कभी नहीं पहुँचता, फर्स्ट वैल्यू तक का मध्यमान समय, और एक घंटे के भीतर फर्स्ट वैल्यू तक पहुँचने वाला हिस्सा।"

फर्स्ट वैल्यू तक पहुँचना भविष्य के ग्राहक का सबसे स्पष्ट प्रारंभिक संकेत है। रूपांतरित अकाउंट में से 97% इस तक पहुँचे, जबकि ठंडे पड़ गए अकाउंट में से 41%। केवल 3% ग्राहक कभी नहीं पहुँचे, जबकि गैर-ग्राहकों में से 59%। रूपांतरित अकाउंट वहाँ थोड़ा तेज़ी से भी पहुँचते हैं। यह association है, कारण-कार्य का प्रमाण नहीं, लेकिन यह एक ऐसा संकेत है जिसके आसपास onboarding बनाने लायक है।

time-to-first-value की तुलना करें: रूपांतरित बनाम ठंडा
5 चरण 5:

सुधारों की प्राथमिकता-सूची तैयार करें

इसे एक रैंक की गई सूची में एक साथ लाएँ: ठीक करने के लिए onboarding चरण, हर एक द्वारा खोए गए अकाउंट के अनुसार क्रमबद्ध। फिर Querri को वह विवरण लिखने दें जिसकी आपकी growth और उत्पाद टीमों को यह तय करने के लिए ज़रूरत है कि पहले क्या ठीक करना है।

Querri जो विवरण लिखता है:

2,400 नए साइनअप में से, 1,149 फर्स्ट वैल्यू तक पहुँचते हैं (47.9%)। लीक एक समान नहीं हैं, इसलिए उन्हें खोए गए अकाउंट के क्रम में ठीक करें।

  • import अड़चन है: 563 अकाउंट एक स्रोत कनेक्ट करते हैं लेकिन कभी पहला import पूरा नहीं करते (30%), आमतौर पर एक import त्रुटि। इसे पहले ठीक करें।
  • Paid Search सबसे अधिक साइनअप लाता है लेकिन सबसे कम फर्स्ट-वैल्यू rate (31%); Referral और Partner लगभग 70% पर वैल्यू तक पहुँचते हैं।
  • फर्स्ट वैल्यू राजस्व की भविष्यवाणी करती है: 97% ग्राहक इस तक पहुँचते हैं, जबकि ठंडे पड़ गए अकाउंट में से 41%।
  • v2 onboarding ने पहले ही connect-to-import को 66% से 74% तक बढ़ा दिया है।

आप क्या बना या एक्सपोर्ट कर सकते हैं:

  • एक 10-स्लाइड कार्यकारी प्रस्तुति जिसे आप लाइव प्रस्तुत कर सकते हैं, लिंक द्वारा साझा कर सकते हैं, या डाउनलोड कर सकते हैं
  • फ़नल, स्रोत-विभाजन, और प्राथमिकता-सुधार तालिकाएँ, Excel, CSV, या Google Sheets में एक्सपोर्ट करने योग्य
  • फ़नल और cohort चार्ट (stage drop-off, स्रोत के अनुसार फर्स्ट-वैल्यू rate, time-to-first-value) PNG या SVG के रूप में
  • एक पुन: प्रयोज्य पहचान सेतु जो Amplitude, HubSpot, और Salesforce को अकाउंट-स्तरीय रिकॉर्ड में एकीकृत करता है, match-coverage सारांश के साथ
  • एक सहेजा गया प्रोजेक्ट जिसे आप नए साइनअप और events आने पर फ़नल को ताज़ा करने के लिए स्वचालित कर सकते हैं
सुधारों की प्राथमिकता-सूची तैयार करें

एक फर्स्ट-वैल्यू फ़नल के लिए सुझाव जिस पर आपकी टीम कार्रवाई कर सके

फर्स्ट वैल्यू को प्राप्त वैल्यू के रूप में परिभाषित करें, न कि पूर्ण सेटअप

"Onboarding पूरा किया" और "लॉग इन किया" फर्स्ट वैल्यू नहीं हैं। वह पहली event चुनें जहाँ अकाउंट वास्तव में वह लाभ प्राप्त करता है जिसके लिए वह आया था, यहाँ एक पूर्ण विश्लेषण परिणाम, और उसे स्पष्ट रूप से घोषित करें। वह एक परिभाषा तय करती है कि फ़नल क्या मापता है।

फ़नल को अकाउंट स्तर पर मापें

कई उपयोगकर्ता एक कंपनी के होते हैं, और राजस्व अकाउंट पर आता है। उत्पाद events को अकाउंट तक रोल करें ताकि activation, स्रोत, और रूपांतरण सभी एक ही इकाई पर पंक्तिबद्ध हों। व्यक्तिगत उपयोगकर्ताओं का उपयोग केवल तभी करें जब आप विशेष रूप से per-seat अपनाव माप रहे हों।

सुधारों को खोए गए अकाउंट के अनुसार रैंक करें, drop-off दर के अनुसार नहीं

एक ऐसे चरण पर 30% नुकसान जहाँ हर कोई पहुँचता है, एक ऐसे चरण पर 50% नुकसान से बेहतर है जहाँ लगभग कोई नहीं पहुँचता। खोए गए अकाउंट के अनुसार रैंक करें, drop-off दर के अनुसार नहीं, और उसी क्रम में ठीक करें।

अटकाव को हमेशा स्रोत के अनुसार विभाजित करें

एक औसत फ़नल असली कहानी को छिपा देता है। यहाँ Paid Search, Referral की तुलना में चार गुना अधिक बार import पर अटकता है। हर drop-off को acquisition स्रोत के अनुसार विभाजित करें ताकि आप onboarding चरण को ठीक कर सकें और उसे भरने वाले खर्च पर सवाल उठा सकें।

time-to-first-value को एक KPI के रूप में ट्रैक करें

time to first value बस फर्स्ट-वैल्यू टाइमस्टैम्प घटा साइनअप टाइमस्टैम्प है, और यह Querri के Five Dimensions में Efficiency और Quality दोनों में फैला है। मध्यमान, 25वें और 75वें पर्सेंटाइल, और एक घंटे, एक दिन, और एक सप्ताह के भीतर वैल्यू तक पहुँचने वाले हिस्से को ट्रैक करें।

क्या आपके पास एक Data Dictionary है? उसे लाएँ। नहीं है? Querri में एक पहला ड्राफ्ट बनाएं।

एक Data Dictionary दस्तावेज़ करता है कि आपके डेटा में फ़ील्ड का क्या अर्थ है, महत्वपूर्ण व्यावसायिक शब्द कैसे परिभाषित हैं, और विभिन्न सिस्टम एक-दूसरे से कैसे संबंधित हैं। इस playbook में हमने एक नमूना Data Dictionary शामिल किया है ताकि Querri के पास संदर्भ हो कि हर फ़ील्ड क्या दर्शाता है और Amplitude, HubSpot, और Salesforce डेटा की व्याख्या कैसे की जानी चाहिए। आपकी अपनी कंपनी में वह संदर्भ किसी spreadsheet, आंतरिक wiki, tracking plan, CRM दस्तावेज़, या data catalog में हो सकता है।

मुझे दिखाएं कि एक कैसे लाएँ या बनाएं

यदि आपके पास पहले से एक Data Dictionary है

इसे उस डेटा के साथ अपलोड करें जिसका आप विश्लेषण करना चाहते हैं और Querri को बताएं कि आप इसका उपयोग कैसे करना चाहते हैं। Querri एक प्रोजेक्ट में कई Sources में काम कर सकता है, उनकी संरचना और सामग्री की जाँच कर सकता है, डेटा प्रकार और संबंधों की पहचान कर सकता है, और आवश्यकता पड़ने पर Sources को जॉइन कर सकता है।

Prompt

"इस प्रोजेक्ट में Amplitude, HubSpot, और Salesforce डेटा की व्याख्या के लिए हमारे Data Dictionary को संदर्भ के रूप में उपयोग करें। फ़ील्ड, व्यावसायिक शब्दावली, और Sources के बीच ज्ञात संबंधों के लिए इसकी परिभाषाओं का उपयोग करें। यदि डेटा dictionary के साथ विरोधाभासी प्रतीत होता है, तो कोई धारणा बनाने के बजाय विरोध को चिह्नित करें।"

यदि आपके पास एक Data Dictionary नहीं है

एक उपयोगी पहला ड्राफ्ट बनाने के लिए Querri का उपयोग करें। उन Sources को अपलोड करें जिन्हें आप दस्तावेज़ करना चाहते हैं, फिर Querri से उनका निरीक्षण करने और एक अच्छे dictionary के लिए आवश्यक हर चीज़ के साथ एक तालिका बनाने को कहें:

  • Source नाम
  • फ़ील्ड या column नाम
  • अनुमानित डेटा प्रकार
  • उदाहरण मान
  • संभावित व्यावसायिक अर्थ
  • अन्य Sources में फ़ील्ड के साथ संभावित संबंध
  • सवाल या अस्पष्टताएँ जिनके लिए मानवीय स्पष्टीकरण की आवश्यकता है
Prompt

"इस प्रोजेक्ट में Sources की समीक्षा करें और एक पहला-पास Data Dictionary बनाएं। हर फ़ील्ड के लिए, Source, फ़ील्ड नाम, अनुमानित डेटा प्रकार, उदाहरण मान, संभावित व्यावसायिक अर्थ, और कोई भी फ़ील्ड जो Sources को जॉइन करने के लिए उपयोगी प्रतीत हों, दिखाएं। जिन परिभाषाओं को आप आत्मविश्वास से निर्धारित नहीं कर सकते उन्हें अनुमान लगाने के बजाय चिह्नित करें।"

फिर वह व्यावसायिक संदर्भ जोड़ें जो केवल आपकी टीम जानती है

Querri डेटा से ही बहुत कुछ अनुमान लगा सकता है, लेकिन कुछ परिभाषाओं के लिए मानवीय ज्ञान की आवश्यकता होती है। Querri पहचान सकता है कि first_analysis_completed एक Amplitude event है, लेकिन आपकी टीम को फिर भी यह कहना होगा कि यही वह event है जिसका उपयोग आप फर्स्ट वैल्यू परिभाषित करने के लिए करते हैं। अन्य नियम जो Querri केवल डेटा से नहीं सीख सकता:

  • company_domain, HubSpot कंपनियों को Salesforce अकाउंट से मिलाने के लिए पसंदीदा key है
  • आंतरिक कर्मचारी अकाउंट को ग्राहक विश्लेषण से बाहर रखा जाना चाहिए
  • "रूपांतरित" का अर्थ है कि एक Salesforce opportunity, Closed Won तक पहुँची
  • एक विशिष्ट HubSpot फ़ील्ड acquisition channel के लिए सत्य का स्रोत है

अपनी मानक परिभाषाएँ एक बार सहेजें

जब कोई परिभाषा एक कंपनी मानक हो, तो इसे हर chat में दोहराने के बजाय एक बार सहेजें। संगठन-व्यापी नियम Context Settings में जोड़ें, और Querri उन्हें आपकी टीम द्वारा चलाए जाने वाले हर विश्लेषण पर स्वचालित रूप से लागू करता है। बड़ी तस्वीर के लिए, Querri Library वह जगह है जहाँ आपकी कंपनी का डेटा संदर्भ रहता है: यह आपके व्यवसाय को सीखता है और आपके sources, परिभाषाओं, और व्यावसायिक नियमों को हर जगह सुसंगत रखता है। एक बार जब आपका dictionary सही दिखे, तो आप इसे Querri के बाहर उपयोग के लिए CSV या Excel में एक्सपोर्ट कर सकते हैं।

एक अच्छा Data Dictionary मानवीय समीक्षा से बेहतर होता है

Querri के जनरेट किए गए dictionary को एक शुरुआती बिंदु समझें, अंतिम प्राधिकरण नहीं। Querri थकाऊ हिस्सा करता है: फ़ील्ड का प्रोफ़ाइल बनाना और परिभाषाएँ प्रस्तावित करना। आपकी टीम व्यावसायिक अर्थ की पुष्टि करती है, अस्पष्ट परिभाषाओं को सुधारती है, और वे नियम जोड़ती है जो डेटा से नहीं सीखे जा सकते। यह आपको column नामों की सूची से कहीं अधिक उपयोगी कुछ देता है। यह आपको इस बात का एक साझा संदर्भ देता है कि आपकी कंपनी वास्तव में अपने डेटा को कैसे समझती है।

अक्सर पूछे जाने वाले सवाल

"फर्स्ट वैल्यू" वास्तव में क्या है?
फर्स्ट वैल्यू वह पहला क्षण है जब कोई उपयोगकर्ता वास्तव में वह लाभ प्राप्त करता है जिसके लिए उसने साइन अप किया था, न कि वह क्षण जब वह सेटअप पूरा करता है या लॉग इन करता है। इस playbook में हम इसे first_analysis_completed के रूप में परिभाषित करते हैं: पहली बार जब किसी अकाउंट को एक पूर्ण, उपयोगी विश्लेषण परिणाम मिलता है। इसे अच्छी तरह परिभाषित करना आधा काम है, क्योंकि "onboarding पूरा किया" और "वैल्यू मिली" एक ही बात नहीं है।
सिर्फ एक Amplitude फ़नल का उपयोग करने के बजाय Amplitude, HubSpot और Salesforce को क्यों जोड़ें?
Amplitude आपको बताता है कि लोगों ने क्या किया, इसलिए यह दिखाता है कि वे कहाँ अटकते हैं। HubSpot जोड़ता है कि हर साइनअप कहाँ से आया, ताकि आप देख सकें कि कौन-से स्रोत सबसे अधिक अटकते हैं। Salesforce बताता है कि क्या वह अकाउंट कभी राजस्व बना। केवल तीनों को जोड़कर ही आप onboarding सुधारों को उन अकाउंट और राजस्व के अनुसार रैंक कर सकते हैं जो वास्तव में दांव पर हैं।
आप तीन सिस्टम में रिकॉर्ड कैसे मिलाते हैं जो एक ID साझा नहीं करते?
जहाँ भी मौजूद हो वहाँ एक आंतरिक अकाउंट ID पर जॉइन करें, फिर Amplitude और HubSpot के बीच सामान्यीकृत email पर और HubSpot व Salesforce के बीच company domain पर वापस आ जाएँ। सब कुछ लोअरकेस करें, domains से whitespace और formatting शोर हटाएँ, और हमेशा अपनी match rate रिपोर्ट करें ताकि किसी डेटा-गुणवत्ता कमी को कभी भी फ़नल परिणाम समझने की गलती न हो।
क्या फर्स्ट वैल्यू एक single event होनी चाहिए या पूरा sequence?
एक स्पष्ट event चुनें जो प्राप्त वैल्यू को दर्शाती हो और उसे स्पष्ट रूप से घोषित करें। आप फिर भी यह आवश्यक कर सकते हैं कि पहले के चरण पहले हुए हों, लेकिन वैल्यू का क्षण स्वयं एक ऐसी single event होना चाहिए जिस पर सभी सहमत हों, ताकि फ़नल और time-to-first-value दोनों घड़ियों के पास एक साफ़ स्टॉप पॉइंट हो।
यह एक साधारण onboarding फ़नल से कैसे अलग है?
एक साधारण फ़नल आपको बताता है कि अकाउंट कहाँ छूटते हैं। यह जोड़ता है कि कौन छूट रहा है (acquisition स्रोत) और क्या यह मायने रखता है (अंतिम रूपांतरण), ताकि आप कच्ची drop-off दर के बजाय जोखिम में राजस्व के अनुसार प्राथमिकता तय कर सकें। एक ऐसे चरण पर 30% नुकसान जहाँ हर कोई पहुँचता है, आमतौर पर एक ऐसे चरण पर 50% नुकसान से अधिक मायने रखता है जहाँ लगभग कोई नहीं पहुँचता।
क्या तेज़ time-to-first-value केवल रूपांतरण से सहसंबंधित होता है, न कि उसका कारण बनता है?
सही, यह association है, कारण-कार्य का प्रमाण नहीं। जो अकाउंट जल्दी वैल्यू तक पहुँचते हैं वे शुरू से ही अधिक प्रेरित होते हैं। time-to-first-value को एक मजबूत अग्रणी संकेतक के रूप में लें, फिर onboarding परिवर्तनों का परीक्षण करें और देखें कि क्या इसे बदलने से वास्तव में रूपांतरण बदलता है, जो ठीक वैसे ही है जैसे यहाँ v2 onboarding परिवर्तन को मान्य किया गया था।
इसे बनाने में कितना समय लगता है?
पहला निर्माण असली काम है: तीन स्रोतों को जोड़ना, फर्स्ट वैल्यू परिभाषित करना, और जॉइन नियम तय करना। उसके बाद, फ़नल को ताज़ा करने में कुछ मिनट लगते हैं, और आप इसे एक शेड्यूल्ड प्रोजेक्ट के रूप में सहेज सकते हैं जो नए साइनअप और events आने पर स्वयं फिर से चलता है।