تحليل البيانات على الشبكة باستخدام Dune SQL واكتشاف السيبل

غالباً بيقع بتوع الماركتنج ومحللي المنتجات في نفس الغلطة، وهي تقييم مستخدمين الـ dApp بناءً على حجم السيولة في محافظهم (زي متريكس الـ TVL أو الـ Balance). بمجرد ما يلمحوا محفظة فيها 50 ETH، بيصنفوها علطول كـ Core User. الكلام ده وهم كبير وغلط سيستماتيك.

في الـ Web3 Analytics، الرصيد الحالي مش هو الأساس، الأهم هو مصدر التمويل الأول للمحفظة (Funding Source). تحليل السلوك الصح (User Behavior Analytics) بيبدأ من كشف الروابط المخفية بين المحافظ (Cluster Analysis). لو لاحظت فجأة طفرة بـ 1000 محفظة جديدة في البروتوكول، ولقيت بعد الفحص إن كلهم استلموا أول Gas ليهم من Sub-account تابع لمنصة تداول كبيرة، أو من Smart Contract بتاع ميكسر في وقت واحد وقريب جداً من بعض، فده مش نمو حقيقي (Organic). دي في الغالب Sybil Farm احترافية وشغالين بشكل منظم عشان يسحبوا السيولة أو يعملوا Fake Activity عشان الـ Airdrop الجاي.

وعشان نكشف الـ Patterns دي، بنحلل الـ "Genesis" للمحفظة: يعني الـ Timestamp لأول Transaction، والـ Donor Address، وسلسلة الـ Transfers اللي حصلت بعد كده.

كود SQL عملي لمنصة Dune (Dune SQL)

الـ Script ده بيعزل المحافظ اللي اتفاعلت مع الـ Smart Contract بتاعك، وبيطلع أول Transaction عملتها المحافظ دي على الشبكة من يوم ما اتعملت. ده بيخليك تقسم المستخدمين في ثواني بناءً على نوع الـ "Donor" بتاعهم.

-- بنحدد المصدر الأول للـ Gas للمحافظ اللي اتفاعلت مع العقد
WITH target_users AS (
    SELECT DISTINCT "from" AS user_address
    FROM ethereum.transactions
    WHERE "to" = c'0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640' -- مثال: Pool لـ 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,
    -- بنعلم على الـ Funders المشبوهين. العناوين اللي تحت دي أمثلة لعقود ميكسرز وجسور كبيرة
    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 على جدول العمليات بالكامل. مع الداتا الكبيرة استخدم partitions بناءً على block_date.

تقسيم المستخدمين: سرعة اتخاذ القرار ومنطق الـ Gas

الـ Behavioral Analysis بيقسم المستخدمين لفئات واضحة بناءً على انضباطهم الـ On-chain. الاستبيانات المباشرة هنا مش هتنفع، لأن المستخدمين بيكذبوا، بس الـ Chain مابتكذبش.

ومن أقوى المعايير اللي نادراً ما بتستخدم في الـ Segmentation هي الـ Approve-to-Swap Latency (الفارق الزمني بين الموافقة على استخدام التوكن وبين عملية الـ Swap نفسها).

المستخدم الـ Retail العادي بيتعامل بواجهات عادية زي MetaMask أو Rabby. الفارق بين استدعاء دالة approve() وإرسال swap() بياخد من 15 ثانية لدقائق، لأنه بيراجع الـ Slippage، أو بيفكر، أو بيتشغل في حاجة ثانية. في المقابل، الـ Scripts المؤتمتة والـ MEV Bots بتوقع الـ Transactions دي بشكل ذري (Atomic)، وبتنزل يا في نفس الـ Block أو في نفس الـ Flashbots bundle. لو لقيت الفارق الزمني بين الـ Approve والـ Transfer قريب من الصفر، علم على المحفظة دي علطول إنها Bot.

مقارنة بين الـ On-chain Patterns

تحليل الاحتفاظ بالمستخدمين (Cohort Retention) عبر Dune SQL

عشان تتأكد من إن منتجك واصل لمرحلة الـ Product-Market Fit (PMF) فعلاً، ومش مجرد إنك بتمشّي ميزانية الماركتنج على مستخدمين بيجوا مرة واحدة ويمشوا، لازم تعمل Cohort Analysis. محتاجين نراقب سلوك اليوزرز اللي بدأوا في شهر معين ونشوف هيعملوا إيه في الفترات اللي بعد كده.

في Dune SQL بنستخدم الـ Window Functions وبنحسب الفارق بين التواريخ بـ DATE_DIFF.

-- بنحسب الـ Retention الشهري للمستخدين لعقد ذكي معين
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 (
    -- بنثبت الحجم الابتدائي لكل مجموعة (Cohort)
    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;
-- مؤشر خطر: لو الـ retention_percentage في الشهر الثاني (period_index = 1) نزل تحت 7%، يبقى عندك مشكلة حقيقية في الـ Retention.

بس لحظة، في نقطة مهمة هنا. لو العقد ده أساسي في السيستم (زي الـ USDT في المثال)، الـ Cohorts هتكون ضخمة جداً، والـ Query ممكن يحصلها Timeout لو شغال على باقة Dune المجانية. لكن لو dApp مخصص وصغير الكود هيشتغل في ثواني.

الـ Events المستخبية: كيف تطلع مؤشرات السلوك العميقة من الـ Logs

معظم المحللين بيكتفوا بـ Parsing لجداول الـ transactions أو الـ traces، وده بيطير جزء كبير من الداتا. التحليل الاحترافي بجد بيحتاج غوص في الـ System Logs (جدول ethereum.logs).

ليه ده مهم؟ لأن بروتوكولات كتير حالياً بتعتمد على الـ Meta-transactions والـ Account Abstraction (ERC-4337). في الحالة دي، حقل tx.from دايماً هيكون فيه عنوان الـ Relayer (اللي بيجمع وبيدفع العمليات للشبكة) مش عنوان المستخدم الحقيقي. فلو حللت الـ Transactions العادية، هتشوف نشاط لـ 3 أو 4 عقود ضخمة بس بدل ما تشوف آلاف المستخدمين الحقيقيين.

الحل هنا إنك تطلع الداتا من الـ Events نفسها. مثلاً، تعمل Parsing لـ Topic 0 مع الـ Hash لحدث الـ UserOperationEvent. ده هيخليك تعرف هل المستخدم شغال بـ Smart Contract Wallet (زي Safe أو Argent)، ولا شغال بـ Hardware Wallet، ولا بيتفاعل مع الـ dApp من خلال الـ Embedded Wallets اللي جوه بوتات تليجرام. لما تفهم بنية محافظ جمهورك، هتعرف تحسن الـ UX صح: الـ Retail اللي عندهم Smart Accounts مش محتاج تشرح لهم يعني إيه Gas، أنت محتاج تظبط لهم عقود الـ Paymaster عشان يدفعوا الرسوم بالـ Stablecoins علطول.

تتبع السيولة الشامل: رصد أنماط سحب السيولة (LP Drain)

بمجرد أن يطلق أي مشروع حملة لتعدين السيولة (Liquidity Mining)، تتدفق جموع مزودي السيولة (LPs) على الحوض. المشكلة تكمن في أن جزءاً كبيراً من هذه الأموال هو "رأس مال مضارب" (Mercenary Capital). يستقر هؤلاء المزارعون في الحوض فقط طالما أن العائد السنوي (APY) المرتفع مستمر، ثم يسحبون أموالهم فجأة، مما يؤدي إلى انهيار عمق السوق (Market Depth).

لبناء نظام إنذار مبكر قوي، لا يكفي مجرد رصد واقعة سحب السيولة. يجب تتبع الوجهة التالية لهذه الأموال بدقة. سلوك المحافظ الذكية (Smart Money) يختلف تماماً عن سلوك صغار المستثمرين (Retail) عند جني الأرباح.

• محافظ التجزئة (Retail): سحب توكنات السيولة -> تحويلها فوراً إلى عملات مستقرة أو عملة الغاز الأساسية (ETH) -> إيداعها في المنصات المركزية (CEX) عبر عناوين الإيداع القياسية.
• المضاربون وبوتات الـ MEV: سحب السيولة -> نقلها في نفس اللحظة إلى حوض مماثل في بروتوكول آخر يوفر عائداً أعلى ولو بنسبة 0.5% -> تنفيذ العملية كاملة خلال بلوك واحد أو اثنين.
• الحيتان والمؤسسات: نقل الأموال إلى محفظة متعددة التوقيع (Multisig) أو بروتوكولات الإقراض غير الحاضنة مثل Aave أو Maker. يتم استخدام الأصول كضمان (Collateral) للحصول على خطوط ائتمان بدلاً من البيع المباشر.

كتابة استعلام SQL متقدم لتتبع هجرة الـ LPs

لنكتب استعلاماً يعزل المحافظ التي سحبت السيولة من الحوض (حدث 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;
-- حالة خاصة: إذا نفذ المستخدم عمليات متعددة في نفس الثانية (bundle)، قد يختل ترتيب tx_order.

تحليل "التدفق السام" (Toxic Flow) وأثره على مقاييس المنتج

فهم جودة حجم التداول (Volume) مسألة حياة أو موت لأي منصة تداول لامركزية (DEX) أو بروتوكول DeFi. ينقسم الحجم على الشبكة إلى قسمين: حجم عضوي (Organice) ناتج عن مستخدمين حقيقيين، وحجم سام (Toxic Flow) مدفوع بالمضاربة واقتناص الفوارق السعرية (Arbitrage / LVR).

تولد البوتات هذا التدفق السام. بمجرد حدوث حركات سعرية حادة في الأسواق الخارجية (مثل Binance)، تقوم هذه البوتات بامتصاص القيمة من مزودي السيولة غير النشطين. إذا رصد المحلل قفزة في الأحجام على التطبيق اللامركزي (dApp) واعتبرها دليلاً على نمو المستخدمين، فهو مخطئ تماماً. في كثير من الأحيان، يكون أوراكل (Oracle) البروتوكول متأخراً فقط، والبوتات تقوم بحلب الحوض بنجاح.

كيف تكتشف العناوين السامة عبر SQL؟

نراقب مقياس الأرباح والخسائر (PnL) للمعاملة عبر نافذة من 5 بلوكات بعد التنفيذ. إذا قام عنوان بعملية مبادلة (Swap)، وتحرك السعر خلال البلوكات الخمسة التالية باتجاه يضر بالحوض ويفيد المحافظ التي نفذت العملية، فهذا يعني مضاربة بحتة (Pure Arbitrage).

المحافظ التي تشكل هذه العمليات أكثر من 80% من إجمالي حجم تداولها يجب تصنيفها في قاعدة البيانات التحليلية بوسم Arbitrage_Bot. عند حساب معدل الاحتفاظ الحقيقي بالمستخدمين (Retention)، يجب استبعاد هذه الأحجام تماماً من الإحصاءات الأساسية، وإلا ستظهر مقاييس التفاعل (Engagement) بشكل وهمي ومضلل.

هندسة لوحة البيانات التحليلية: من السجلات الخام إلى رؤى المنتج

لا يمكن للتحليل الاحترافي على الشبكة (On-chain) أن يعتمد على استعلامات يدوية عشوائية. عملياً، يتم تجميع البيانات الخام في جداول مخصصة (تُعرف باسم Spells في بيئة Dune) تُحدث تلقائياً عبر جدولة Cron منتظمة.

فيما يلي الهيكل المعتمد لخط أنابيب البيانات (Data Pipeline) الخاص بتحليل منتجات Web3:

[البيانات الخام للشبكة (Blocks, Transactions, Logs)]
                      │
                      ▼
[العقود المفككة (Events & Calls)] ──► تنظيف ضوضاء النظام والعمليات الفاشلة (reverted)
                      │
                      ▼
[طبقة منطق العمل (جداول Spells: Swaps, Deposits)] ──► الفرز بناءً على زمن الاستجابة بين التوفير والمبادلة
                      │
                      ▼
[المجموعات السلوكية (اللوحة النهائية)] ──► مقاييس المنتج (LTV, CAC, Retention)

الخلاصة الأساسية للمحلل

توقف عن تقييم منتجات Web3 بمقاييس Web2 التقليدية. عدد المحافظ النشطة الفريدة (UAW) وإجمالي حجم المعاملات (Volume) مقاييس يسهل تزويرها عبر هجمات Sybil بتكلفة غاز ضئيلة. التحليل السلوكي الحقيقي يكمن في تتبع الجذور المالية للمحافظ (مصدر الغاز)، والفوارق الزمنية بين استدعاءات النظام، ومسار حركة رأس المال بعد التفاعل مع عقودك الذكية. البلوكشين لا يكذب أبداً، عليك فقط معرفة كيفية استجوابه بشكل صحيح.