Growth Marketers और प्रोडक्ट एनालिस्ट अक्सर एक ही गलती बार-बार करते हैं। वे dApp की ऑडियंस को उनके वॉलेट बैलेंस या TVL देखकर जज करने लगते हैं। किसी एड्रेस पर 50 ETH दिखा नहीं कि उसे तुरंत 'हाई-वैल्यू यूजर' की केटेगरी में डाल दिया जाता है। Web3 एनालिटिक्स में यह बहुत बड़ा मिथ है।
यहाँ मौजूदा बैलेंस कोई मायने नहीं रखता, बल्कि असली सिग्नल 'Funding Source' (शुरुआती फंड कहाँ से आया) से मिलता है। सटीक यूजर बिहेवियर एनालिसिस (User Behavior Analytics) के लिए वॉलेट्स के बीच के कनेक्शन को डी-एनोनिमाइज करना जरूरी है। मान लीजिए आपके प्रोटोकॉल पर अचानक 1,000 नए एड्रेस आ जाते हैं। ऑन-चेन चेकिंग के बाद पता चलता है कि उन सबको पहला गैस फीस फंड किसी बड़े CEX के एक ही सब-अकाउंट से या किसी मिक्सर के कस्टम स्मार्ट कॉन्ट्रैक्ट से बहुत कम टाइम-विंडो के अंदर मिला है। तो भाई, यह ऑर्गेनिक ग्रोथ बिल्कुल नहीं है। यह सीधे-सीधे एक कमर्शियल सिबिल फार्म (Sybil Farm) है, जो लिक्विडिटी ड्रेन करने या फ्यूचर एयरड्रॉप के चक्कर में फेक एक्टिविटी जेनरेट कर रहा है।
ऐसे पैटर्न्स को पकड़ने के लिए वॉलेट का 'Genesis' ट्रैक किया जाता है। इसमें पहली ट्रांजैक्शन का टाइमस्टैम्प, डोनर एड्रेस और उसके बाद की पूरी ट्रांसफर चेन को खंगाला जाता है।
Dune के लिए प्रैक्टिकल SQL क्वेरी (Dune SQL)
यह स्क्रिप्ट आपके स्मार्ट कॉन्ट्रैक्ट के साथ इंटरैक्ट करने वाले एड्रेस को आइसोलेट करेगी। फिर ऑन-चेन डेटा से उनकी सबसे पहली ट्रांजैक्शन निकालकर लाएगी। इससे आप यूजर्स को उनके 'डोनर' टाइप के हिसाब से तुरंत बकेट कर सकते हैं।
-- कॉन्ट्रैक्ट से इंटरैक्ट करने वाले एड्रेस के लिए पहला गैस सोर्स ढूंढें
WITH target_users AS (
SELECT DISTINCT "from" AS user_address
FROM ethereum.transactions
WHERE "to" = c'0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640' -- एग्जांपल: Uniswap v3 USDC/WETH पूल
LIMIT 500
),
genesis_transactions AS (
SELECT
t."to" AS user_address,
t."from" AS funder,
t.block_time,
ROW_NUMBER() OVER (PARTITION BY t."to" ORDER BY t.block_time ASC) as rank_index
FROM ethereum.transactions t
JOIN target_users u ON t."to" = u.user_address
)
-- हर वॉलेट की पहली हिस्टोरिकल ट्रांजैक्शन के अलावा बाकी सब फ़िल्टर करें
SELECT
g.user_address,
g.funder AS parent_address,
g.block_time AS creation_timestamp,
-- संदेहास्पद फंडर्स को फ्लैग करें। नीचे दिए एड्रेस बड़े मिक्सर/ब्रिज कॉन्ट्रैक्ट के उदाहरण हैं
CASE
WHEN g.funder = c'0x12d66748a9176f0af33dfc592215a425441047f1' THEN 'Tornado.Cash (0.1 ETH)'
WHEN g.funder = c'0x47ce0c6ed5b0ce3d3a51fdb1c52dc66a7c3c2936' THEN 'Tornado.Cash (1.0 ETH)'
ELSE 'CEX Sub-account / Standard EOA'
END AS funder_classification
FROM genesis_transactions g
WHERE g.rank_index = 1
ORDER BY g.block_time DESC;
-- पूरी ट्रांजैक्शन टेबल पर JOIN होने के कारण क्वेरी हैवी है। बड़े डेटासेट के लिए block_date पर पार्टीशन यूज़ करें।ऑडियंस सेगमेंटेशन: एग्जीक्यूशन लेटेंसी और गैस लॉजिक
बिहेवियरल एनालिसिस से आप यूजर्स को उनकी ऑन-चेन एक्टिविटी के आधार पर क्लियर केटेगरी में बांट सकते हैं। यहाँ सीधे सर्वे काम नहीं आते; यूजर्स झूठ बोल सकते हैं, लेकिन लेजर झूठ नहीं बोलता।
सेगमेंटेशन का एक बहुत ही असरदार लेकिन अंडर-यूज़्ड पैरामीटर है—Approve-to-Swap Latency (टोकन अप्रूवल और एक्चुअल स्वैप के बीच का टाइम गैप)।
नॉर्मल रिटेल यूजर MetaMask या Rabby जैसे स्टैंडर्ड UI का इस्तेमाल करता है। उसे approve() फंक्शन कॉल करने और फिर swap() पर क्लिक करने में कम से कम 15 सेकंड से लेकर कुछ मिनट तक का समय लग जाता है। वह स्लिपेज चेक करता है, सोचता है या उसका ध्यान कहीं और भटक जाता है। इसके उलट, स्क्रिप्ट्स और MEV बॉट्स इन ट्रांजैक्शंस को एटॉमिकली साइन करते हैं। उनकी ट्रांजैक्शंस या तो एक ही ब्लॉक में जाती हैं या फिर एक सिंगल Flashbots बंडल के जरिए निकलती हैं। अगर अप्रूवल और ट्रांसफर के बीच का टाइम डिफरेंस जीरो के करीब है, तो समझ जाइये कि वह एड्रेस एक बॉट है।
ऑन-चेन पैटर्न्स का कम्पेरिजन
| मैट्रिक | अल्गोरिद्मिक एड्रेस (बॉट/सिबिल) | रिटेल यूजर | बड़ा कैपिटल (व्हेल) |
|---|---|---|---|
| गैस ऑप्टिमाइजेशन (Gas Price) | फंड बचाने के लिए एकदम मिनिमम, या फिर फ्रंटरनिंग के लिए बेहद हाई गैस प्राइस | स्टैंडर्ड मार्केट रेट, अक्सर वॉलेट के डिफ़ॉल्ट प्रीसेट की वजह से ज्यादा पे कर देते हैं | बिल्कुल सटीक gwei तक कैलकुलेटेड, MEV से बचने के लिए अक्सर प्राइवेट RPC (Flashbots Protect) का यूज़ करते हैं |
| इंटरैक्शन डेंसिटी | पूरी तरह साइक्लिकल। ट्रांजैक्शंस फिक्स बैच में जाती हैं, जैसे cron job के जरिए हर 24 घंटे में एक बार | बिना किसी पैटर्न के। किसी बड़ी खबर, हाइप या टोकन लिस्टिंग के समय एक्टिविटी अचानक बढ़ जाती है | लो फ्रीक्वेंसी, लेकिन बड़ा वॉल्यूम। पोजीशन लेकर महीनों तक होल्ड करते हैं |
| टोकन डाइवर्सिफिकेशन | सिर्फ टारगेट प्रोटोकॉल के 1-2 मेन एसेट्स पर फोकस | वॉलेट में इलिक्विड टोकन्स का कचरा और मीमकॉइन्स की भरमार | स्टेबल पोर्टफोलियो: नेटिव गैस (ETH/BNB), WBTC और कोर स्टेबलकॉइन्स |
Dune SQL के जरिए कोहोर्ट रिटेंशन एनालिसिस (Cohort Retention)
आपका प्रोडक्ट वाकई Product-Market Fit हासिल कर रहा है या आप सिर्फ मार्केटिंग बजट फूँककर वन-टाइम यूजर्स बटोर रहे हैं, यह जानने के लिए कोहोर्ट एनालिसिस जरूरी है। हमें देखना होगा कि किसी खास महीने में पहली ट्रांजैक्शन करने वाले यूजर्स आगे के महीनों में कैसा बिहेव कर रहे हैं।
Dune SQL में इसके लिए विंडो फंक्शन्स और DATE_DIFF के जरिए डेट डिफरेंस कैलकुलेट किया जाता है।
-- किसी स्पेसिफिक स्मार्ट कॉन्ट्रैक्ट के लिए मंथली यूजर रिटेंशन रेट कैलकुलेट करें
WITH user_activity AS (
SELECT
"from" AS user_address,
DATE_TRUNC('month', block_time) AS tx_month,
MIN(DATE_TRUNC('month', block_time)) OVER (PARTITION BY "from") AS cohort_month
FROM ethereum.transactions
WHERE "to" = c'0xdac17f958d2ee523a2206206994597c13d831ec7' -- एग्जांपल: USDT कॉन्ट्रैक्ट
),
cohort_volumes AS (
-- हर कोहोर्ट का बेसलाइन साइज फिक्स करें
SELECT
cohort_month,
COUNT(DISTINCT user_address) AS cohort_size
FROM user_activity
GROUP BY 1
),
retention_summary AS (
-- हर महीने वापस आने वाले यूनिक यूजर्स काउंट करें
SELECT
a.cohort_month,
DATE_DIFF('month', a.cohort_month, a.tx_month) AS period_index,
COUNT(DISTINCT a.user_address) AS active_users_count
FROM user_activity a
GROUP BY 1, 2
)
-- फ़ाइनल मैट्रिक्स निकालें
SELECT
r.cohort_month,
c.cohort_size,
r.period_index AS months_after_first_tx,
r.active_users_count,
ROUND(CAST(r.active_users_count AS DOUBLE) / c.cohort_size * 100, 2) AS retention_percentage
FROM retention_summary r
JOIN cohort_volumes c ON r.cohort_month = c.cohort_month
WHERE r.period_index >= 0
ORDER BY r.cohort_month ASC, r.period_index ASC;
-- रेड फ्लैग: अगर दूसरे महीने (period_index = 1) का retention_percentage 7% से नीचे गिरता है, तो रिटेंशन में गड़बड़ है।
लेकिन एक कैच है। अगर कॉन्ट्रैक्ट USDT जैसा कोई कोर सिस्टम इंफ्रास्ट्रक्चर है, तो कोहोर्ट साइज बहुत बड़ा होगा। ऐसे में Dune के फ्री टियर पर क्वेरी टाइमआउट हो सकती है। हालांकि, किसी कस्टम dApp के लिए यह कोड चुटकियों में रन हो जाएगा।
हिडन इवेंट्स: सिस्टम लॉग्स से बिहेवियरल ट्रिगर्स कैसे निकालें
ज्यादातर एनालिस्ट सिर्फ transactions या traces टेबल्स को पार्स करके रुक जाते हैं। इससे बहुत सारा जरूरी डेटा छूट जाता है। प्रो-लेवल एनालिसिस के लिए सीधे सिस्टम लॉग्स (ethereum.logs) में उतरना पड़ता है।
इसकी जरूरत क्यों है? आजकल के मॉडर्न प्रोटोकॉल मेटा-ट्रांजैक्शंस और अकाउंट एब्स्ट्रैक्शन (ERC-4337) का जमकर इस्तेमाल कर रहे हैं। इस आर्किटेक्चर में ट्रांजैक्शन टेबल का tx.from फील्ड हमेशा बंडलर या रिलेयर का एड्रेस दिखाएगा, न कि एंड-यूजर का। अगर आप सिर्फ स्टैंडर्ड ट्रांजैक्शंस खंगालेंगे, तो आपको हजारों यूनिक यूजर्स की जगह सिर्फ तीन-चार बड़े कॉन्ट्रैक्ट्स की एक्टिविटी दिखेगी।
इसका सोल्यूशन है—सीधे इवेंट्स (Events) से डेटा निकालना। जैसे, UserOperationEvent के हैश के साथ Topic 0 को पार्स करना। इससे पता चल जाता है कि यूजर स्मार्ट कॉन्ट्रैक्ट वॉलेट (Safe, Argent) यूज़ कर रहा है, हार्डवेयर वॉलेट से काम कर रहा है या टेलीग्राम बॉट्स के इम्बेडेड वॉलेट के जरिए dApp से इंटरैक्ट कर रहा है। अपनी ऑडियंस के वॉलेट आर्किटेक्चर को समझकर आप UX को बेहतरीन तरीके से ऑप्टिमाइज कर सकते हैं। स्मार्ट अकाउंट वाले रिटेल यूजर्स को गैस फीस समझाने की कोई जरूरत नहीं है; बस पेमास्टर (paymaster) कॉन्ट्रैक्ट्स सेट करें ताकि वे सीधे स्टेबलकॉइन्स में फीस पे कर सकें।
लिक्विडिटी का एंड-टू-एंड ट्रैकिंग: एलपी ड्रेन (LP Drain) पैटर्न्स को डिकोड करना
जब भी कोई प्रोजेक्ट लिक्विडिटी माइनिंग कैंपेन शुरू करता है, तो लिक्विडिटी प्रोवाइडर्स (LPs) की भारी भीड़ उमड़ पड़ती है। दिक्कत यह है कि इस टीवीएल (TVL) का एक बड़ा हिस्सा "मर्सिनरी कैपिटल" (mercenary capital) यानी केवल मुनाफे के लिए आया शॉर्ट-टर्म फंड होता है। ये यील्ड फार्मर्स पूल में सिर्फ तब तक टिकते हैं जब तक बूस्टेड एपीवाई (APY) मिल रहा हो। जैसे ही रिवॉर्ड्स कम होते हैं, ये तुरंत फंड निकालकर मार्केट डेप्थ (market depth) क्रैश कर देते हैं।
एक सॉलिड अर्ली वॉर्निंग सिस्टम बनाने के लिए सिर्फ लिक्विडिटी विथड्रॉल को ट्रैक करना काफी नहीं है। फंड्स पूल से निकलने के बाद आगे कहां जा रहे हैं, इसे ट्रैक करना सबसे जरूरी है। प्रॉफिट बुकिंग के समय स्मार्ट मनी और रिटेल यूजर्स का बिहेवियर पूरी तरह अलग होता है।
- रिटेल एड्रेस (Retail): एलपी टोकन्स निकालना -> उन्हें स्टेबलकॉइन्स या नेटिव गैस (ETH) में स्वैप करना -> स्टैंडर्ड डिपॉजिट एड्रेस के जरिए सेंट्रलाइज्ड एक्सचेंजों (CEX) पर ट्रांसफर करना।
- आर्बिट्राजर्स और एमईवी बॉट्स (MEV Bots): लिक्विडिटी निकालना -> पलक झपकते ही उसे किसी दूसरे प्रोटोकॉल के सिमिलर पूल में मूव कर देना, जहां महज 0.5% ज्यादा एपीवाई मिल रहा हो -> पूरा एक्शन एक या दो ब्लॉक्स के अंदर निपटाना।
- इंस्टीट्यूशनल पूल्स (Whales / Smart Money): फंड्स को सीधे बेचने के बजाय मल्टी-सिग वॉलेट्स या एवे (Aave) और मेकर (Maker) जैसे लेंडिंग प्रोटोकॉल्स में भेजना। वहां इन एसेट्स को कोलैटरल (जमानत) की तरह यूज करके लूपिंग या क्रेडिट लाइन उठाना।
एलपी माइग्रेशन ट्रैक करने के लिए एडवांस्ड SQL क्वेरी
एक ऐसी स्क्रिप्ट लिखते हैं जो पूल से लिक्विडिटी निकालने वाले एड्रेस (Burn इवेंट) को आइसोलेट करे और यह चेक करे कि अगले 24 घंटों में वे टोकन कहां लैंड हुए।
-- लिक्विडिटी रिमूव होने के बाद एलपी का बिहेवियर एनालाइज करना
WITH lp_burns AS (
SELECT
evt_tx_hash,
evt_block_time AS burn_time,
provider AS user_address,
amount0 / 1e6 AS amount_usdc, -- मान लेते हैं टोकन0 USDC है
amount1 / 1e18 AS amount_weth -- मान लेते हैं टोकन1 WETH है
FROM uniswap_v3_ethereum.Pair_evt_Burn
WHERE contract_address = c'0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640' -- टारगेट पूल
AND evt_block_time > CURRENT_DATE - INTERVAL '30' DAY
),
subsequent_txs AS (
SELECT
b.user_address,
b.burn_time,
t.block_time AS tx_time,
t."to" AS destination_address,
ROW_NUMBER() OVER (PARTITION BY b.user_address, b.evt_tx_hash ORDER BY t.block_time ASC) as tx_order
FROM lp_burns b
JOIN ethereum.transactions t
ON t."from" = b.user_address
AND t.block_time > b.burn_time
AND t.block_time <= b.burn_time + INTERVAL '24' HOUR
)
-- पूल से बाहर निकलने के बाद यूजर का पहला एक्शन निकालना
SELECT
s.user_address,
s.burn_time,
s.tx_time,
s.destination_address,
-- टारगेट एड्रेस आइडेंटिफाई करने की कोशिश
CASE
WHEN s.destination_address = c'0x3cd751e6b0078be393132286c442345e5dc49699' THEN 'Binance Deposit'
WHEN s.destination_address = c'0x4675c7e5baafbfc4687441c22105873cd246be3a' THEN 'Hop Protocol Bridge'
WHEN s.destination_address = c'0x7a250d5630b4cf539739df2c5dacb4c659f2488d' THEN 'Uniswap V2 Router'
ELSE 'Unknown EOA / Other Protocol'
END AS next_action_destination
FROM subsequent_txs s
WHERE s.tx_order = 1
ORDER BY s.burn_time DESC;
-- ध्यान दें (Edge Case): अगर यूजर ने एक ही सेकंड में कई ट्रांजैक्शन (bundle) किए हैं, तो tx_order का पार्टिशनिंग गड़बड़ा सकता है।टॉक्सिक वॉल्यूम (Toxic Flow) एनालिसिस और प्रोडक्ट मेट्रिक्स पर उसका असर
किसी भी डेक्स (DEX) या डेफी प्रोटोकॉल के लिए ट्रेडिंग वॉल्यूम की क्वालिटी समझना बेहद क्रिटिकल है। ऑन-चेन डेटा मुख्य रूप से दो हिस्सों में बंटा होता है: ऑर्गेनिक वॉल्यूम (जब यूजर्स अपनी रियल यूटिलिटी के लिए स्वैप करते हैं) और टॉक्सिक वॉल्यूम (आर्बिट्राज, LVR - Loss Versus Rebalancing)।
यह टॉक्सिक वॉल्यूम बॉट्स जनरेट करते हैं। जैसे ही किसी बाहरी मार्केट (जैसे Binance) पर प्राइस तेजी से फ्लक्चुएट होता है, ये बॉट्स पैसिव एलपी से वैल्यू ड्रेन कर लेते हैं। अगर कोई एनालिस्ट डैप (dApp) पर वॉल्यूम बढ़ता देख उसे सीधे यूजर अडॉप्शन मानकर रिपोर्ट कर रहा है, तो वह बहुत बड़ी गलती कर रहा है। अक्सर इसका मतलब सिर्फ यह होता है कि प्रोटोकॉल का ओरैकल (oracle) लैग कर रहा है और आर्बिट्राजर्स पूल को बुरी तरह निचोड़ रहे हैं।
SQL के जरिए टॉक्सिक एड्रेस कैसे स्पॉट करें?
इसके लिए ट्रांजैक्शन के बाद अगले 5 ब्लॉक्स का पीएनएल (PnL) मॉनिटर करना होता है। अगर कोई एड्रेस स्वैप करता है, और अगले 5 ब्लॉक्स के अंदर एसेट का प्राइस इस तरह बदलता है जिससे पूल को नुकसान और उस एड्रेस को फायदा हो – तो यह प्योर आर्बिट्राज है।
जिन एड्रेस का टॉक्सिक फ्लो उनके टोटल वॉल्यूम के 80% से ज्यादा हो, उन्हें एनालिटिक्स डेटाबेस में Arbitrage_Bot का टैग मिलना चाहिए। रियल यूजर रिटेंशन (Retention) कैलकुलेट करते समय, इन वॉल्यूम्स को मेन स्टेट्स से पूरी तरह बाहर रखना जरूरी है। वरना, यूजर इंगेजमेंट मेट्रिक्स (engagement metrics) पूरी तरह फेक और डिस्टॉर्टेड दिखेंगे।
एनालिटिक्स डैशबोर्ड आर्किटेक्चर: रॉ लॉग्स से प्रोडक्ट इनसाइट्स तक का सफर
प्रोडक्शन लेवल पर ऑन-चे恩 (on-chain) एनालिसिस केवल कभी-कभार चलाई जाने वाली एड-हॉक क्वेरीज पर नहीं टिक सकता। प्रैक्टिकल अप्रोच यह है कि रॉ डेटा को कस्टम टेबल्स (ड्यून की भाषा में Spells) में एग्रीगेट किया जाए, जो क्रॉन शेड्यूल के मुताबिक ऑटोमैटिक अपडेट होती रहें।
वेब3 प्रोडक्ट एनालिसिस के लिए एक टेस्टेड डेटा पाइपलाइन का स्ट्रक्चर नीचे दिया गया है:
[नेटवर्क का रॉ डेटा (Blocks, Transactions, Logs)]
│
▼
[डिकोडेड कॉन्ट्रैक्ट्स (Events & Calls)] ──► सिस्टम का शोर और फेल्ड ट्रांजैक्शंस (reverted txs) हटाना
│
▼
[बिजनेस लॉजिक लेयर (Spells टेबल्स: Swaps, Deposits)] ──► Approve-to-Swap Latency के आधार पर फिल्टर करना
│
▼
[बिहेवियरल कोहॉर्ट्स (फाइनल डैशबोर्ड)] ──► प्रोडक्ट मेट्रिक्स (LTV, CAC, Retention)एनालिस्ट के लिए सबसे जरूरी टेकअवे
वेब3 प्रोडक्ट्स को वेब2 के मेट्रिक्स से मापना बंद करना होगा। यूनिक एक्टिव वॉलेट्स (UAW) और टोटल ट्रांजैक्शन वॉल्यूम (Volume) जैसी चीजों को मामूली गैस फीस खर्च करके सिबिल अटैक (Sybil attacks) के जरिए आसानी से मैनिपुलेट किया जा सकता है। असली बिहेवियरल एनालिटिक्स वॉलेट्स की फाइनेंशियल वंशावली (गैस का सोर्स), सिस्टम कॉल्स के बीच का टाइम गैप और कॉन्ट्रैक्ट्स से इंटरैक्ट करने के बाद कैपिटल के मूवमेंट के पैटर्न को ट्रैक करने से आती है। ब्लॉकचेन कभी झूठ नहीं बोलता, बस उससे सही तरीके से क्वेरी करना आना चाहिए।
