بهینه‌سازی نرخ تبدیل (CRO)؛ آزمایش، سود و اعتماد

نرخ خرید ۱۲٪ بالا رفته، اما سود کمتر شده است. تیم CRO خوشحال است؛ بعد معلوم می‌شود نسخه جدید با تخفیف عمومی، سفارش‌های کم‌حاشیه و مرجوعی بیشتر ساخته و رویداد purchase هم دوبار ثبت شده است. «Conversion بیشتر» اگر تعریف، داده و Guardrail درست نداشته باشد می‌تواند یک خطای گران باشد.

بهینه‌سازی نرخ تبدیل (CRO) هنر تغییر رنگ دکمه یا نمایش Popup نیست؛ یک سیستم تصمیم‌گیری است که با تحقیق، آزمایش و داده قابل‌اعتماد، مانع واقعی کاربر را کم می‌کند و Outcome کسب‌وکار را بدون آسیب به سود، اعتماد، دسترس‌پذیری یا حریم خصوصی بهتر می‌سازد. این راهنما برای تیم ایرانی از تعریف Conversion و Instrumentation تا A/B test، MDE، SRM، Personalization، Profit و برنامه ۹۰روزه پیش می‌رود.

به‌روزرسانی ۱۰ اوت ۲۰۲۶: ابزار قدیمی را از Playbook حذف کنید

Google Optimize و Optimize ۳۶۰ از ۳۰ سپتامبر ۲۰۲۳ در دسترس نیستند؛ این موضوع در اعلام رسمی توقف Google Optimize ثبت شده است. بنابراین هر راهنمایی که هنوز آن را ابزار فعال تست معرفی می‌کند، Snapshot عملیاتی معتبری ندارد. ابزار جایگزین را نه با شهرت، بلکه با Assignment، Exposure، SRM، Guardrail، Export، Privacy، Feature flag، Server-side و هزینه واقعی انتخاب کنید.

همچنین «AI هزاران نسخه را خودکار امتحان می‌کند و بهترین را پیدا می‌کند» برنامه CRO نیست. بدون تعریف Objective، محدودیت، Holdout، کنترل خطا، Consent و Human review، Automation فقط سرعت تولید تصمیم نامطمئن را بالا می‌برد.

CRO چیست؟ یک تعریف عملی و قابل ممیزی

CRO فرایند تکرارشونده Measure → Research → Diagnose → Hypothesize → Prioritize → Change/Experiment → Decide → Learn است. Conversion می‌تواند خرید تأییدشده، Lead واجد شرایط، رزرو موفق، فعال‌سازی محصول یا تمدید اشتراک باشد؛ نه هر Clickی که نمودار را سبز می‌کند.

مرز این مقاله با لندینگ، UX و تحلیل بازاریابی

این مقاله مالک Operating system آزمایش و رشد تبدیل در چند Route و Funnel است. برای Message، CTA، فرم و آزمایش صفحه خاص به راهنمای لندینگ پیج و فرم؛ برای ترکیب Analytics و تصمیم طراحی به UX داده‌آگاه؛ و برای Event taxonomy، GA4 و Warehouse به تحلیل داده بازاریابی مراجعه کنید.

CRO جای استراتژی محصول، تحقیق کاربر یا اقتصاد کسب‌وکار نیست. اگر محصول برای بازار مناسب نیست، موجودی ندارید یا پرداخت قطع است، تغییر Copy مشکل را پنهان می‌کند نه حل.

فرمول نرخ تبدیل: صورت و مخرج را قبل از درصد تعریف کنید

فرمول پایه ساده است:

Conversion Rate = Qualified Conversions / Eligible Exposures × 100

اما هر واژه قرارداد می‌خواهد. «Qualified purchase» می‌تواند سفارش پرداخت‌شده و غیرتکراری باشد؛ «Eligible exposure» کاربری است که Variant واقعاً برایش Render شده، محصول قابل‌خرید و درگاه در دسترس بوده است. Session، User، Device و Order مخرج‌های قابل‌جایگزینی نیستند.

تعریف را در میانه آزمایش عوض نکنید. اگر تغییر ضروری شد، Experiment version جدید یا تحلیل از پیش تعریف‌شده بسازید.

Metric tree: Conversion تنها معیار تصمیم نیست

راهنمای Experimentation مایکروسافت نیز Data-quality، OEC، Diagnostic و Guardrail را از هم جدا می‌کند. Click rate نباید جای Profit یا Task success را بگیرد.

Conversion contract: هر رویداد باید معنای واحد داشته باشد

GA4 تعامل‌ها را به‌صورت Event می‌سنجد و Event مهم کسب‌وکار را می‌توان Key event کرد؛ مستند رسمی GA4 Events بر نام، Parameter و DebugView تأکید دارد. بااین‌حال Dashboard ابزار، حقیقت سفارش نیست. برای خرید، Backend/Payment/Order ledger منبع نهایی و Analytics یک View تحلیلی است.

رویداد Click با Outcome برابر نیست

add_to_cart، Scroll و Newsletter signup می‌توانند Micro-conversion باشند، اما فقط وقتی رابطه‌شان با Outcome بررسی شود. Variant ممکن است Add-to-cart را بالا ببرد و Checkout success را پایین بیاورد. Micro-conversion برای تشخیص Funnel است، نه جایزه مستقل تیم.

Data quality قبل از Hypothesis: Garbage in، Confidence out

• Double fire در Refresh، Back، Retry و SPA navigation را تست کنید.
• Client event را با Server truth برای Order/Lead reconcile کنید.
• Timezone، Currency، ریال/تومان، مالیات، ارسال، Coupon و Refund را ثابت کنید.
• Ad blocker، قطع شبکه، Offline queue و Telemetry loss را بر Variant مقایسه کنید.
• Bot، تست داخلی، کارمند، QA order و Fraud را با Rule نسخه‌دار جدا کنید.
• Consent state و تغییر آن را بدون دورزدن انتخاب کاربر ثبت کنید.

پژوهش مایکروسافت درباره Telemetry loss نشان می‌دهد فقدان داده می‌تواند Bias و تصمیم اشتباه بسازد؛ «هر دو Variant کمی داده گم می‌کنند» دلیل بی‌خطربودن نیست.

Funnel را از Promise تا Value و Retention رسم کنید

Funnel فقط Home→Product→Cart→Checkout نیست. هر مرحله یک Promise، Task، Eligibility، Failure و Evidence دارد.

بهینه‌سازی بالای Funnel بدون Fulfillment می‌تواند فقط صف نارضایتی را بلندتر کند.

تحقیق CRO: «چه شد» را با «چرا» و «آیا قابل‌رفع است» ترکیب کنید

Heatmap نمی‌گوید «کاربر CTA را دوست دارد»؛ فقط توزیع Interaction/Attention تخمینی را نشان می‌دهد. برای مشاهده Task با Participant واقعی، راهنمای تست کاربردپذیری را اجرا کنید.

Exit survey را با مانع فعلی هماهنگ کنید

به‌جای «چرا نخریدید؟» برای همه، سؤال کوتاه و Contextual بپرسید: «امروز چه چیزی مانع تکمیل پرداخت شد؟» گزینه‌ها را از داده Support بسازید، «سایر» و متن اختیاری بدهید، Trigger را محدود و پاسخ را با Consent و Retention مشخص نگه دارید.

Session replay و Heatmap بدون Privacy contract ممنوع

Recording می‌تواند داده حساس فرم، جست‌وجو، پیام یا URL را بازسازی کند. Masking باید پیش از ارسال اعمال، Routeهای پرداخت/سلامت/پنل بررسی و دسترسی/Retention محدود شود. FAQ رسمی Microsoft Clarity تصریح می‌کند داده Mask‌شده Upload نمی‌شود و URL parameter masking محدودیت‌های خاص دارد؛ Default ابزار را جای Data map نگذارید.

• هدف، Basis، Consent و Owner را با مشاور حقوقی حوزه فعالیت خود تأیید کنید.
• Inputها، متن شخصی، Query parameter، Referrer و Clicked URL را Threat-model کنید.
• Sampling حداقلی و Retention کوتاه تعریف کنید.
• دسترسی Role-based، Audit log و Export/delete process داشته باشید.
• Session را برای یافتن Pattern ببینید، نه قضاوت فرد یا ذخیره داستان جذاب.

از Evidence به Hypothesis: جمله‌ای که ابطال‌پذیر باشد

Template مناسب:

For [eligible population],
changing [mechanism/intervention]
will improve [primary metric] by at least [MDE]
because [evidence-backed mechanism],
while [guardrails] remain within [limits].

نمونه: «برای کاربران موبایل که محصول موجود را می‌بینند، نمایش هزینه و بازه ارسال پیش از Add-to-cart، Purchase confirmed per eligible user را حداقل ۴٪ نسبی بهتر می‌کند؛ چون ۳۱٪ پاسخ‌دهندگان Survey و ۱۸٪ Ticketها ابهام ارسال دارند؛ Refund، Page load و Support contact نباید بدتر شوند.» عددها در پروژه باید از داده واقعی بیایند، نه از این مثال.

Backlog را با Evidence و Confidence اولویت‌بندی کنید

Frameworkهای ICE/RICE مفیدند، اما Decimal دقیق از ورودی ذهنی علم نمی‌سازد. Assumption و Evidence link را کنار Score نگه دارید.

هر تغییر نیازمند A/B test نیست

Experiment contract قبل از Launch

Assignment با Exposure فرق دارد

کاربر ممکن است به Variant B Assign شود اما هیچ‌وقت Component را نبیند. اگر فقط کاربران Click‌کننده را تحلیل کنید، پس از Treatment شرط گذاشته و Bias می‌سازید. Assignment برای تحلیل Intent-to-treat و Exposure برای Diagnostic هر دو لازم‌اند؛ تعریف دقیق باید قبل از Launch باشد.

Randomization unit را از Contamination محافظت کنید

برای B2B، اعضای یک Account نباید نسخه‌های ناسازگار قرارداد/قیمت ببینند؛ Unit ممکن است Account باشد. برای Marketplace، Treatment فروشنده می‌تواند خریدار دیگر را متاثر کند و فرض استقلال بشکند. Cross-device identity ناقص نیز باید به‌عنوان محدودیت ثبت شود.

MDE، Power و Sample size: «تا معنی‌دار شود» اجرا نکنید

Minimum Detectable Effect کوچک‌ترین اثری است که برای تصمیم ارزش عملی دارد و طراحی باید توان کشفش را داشته باشد. Baseline پایین، Effect کوچک و Variance زیاد Sample بیشتری می‌خواهند. مدت از Traffic خام به‌تنهایی به دست نمی‌آید.

محاسبه را با متخصص آمار یا ابزار معتبر انجام دهید و ورودی/روش را ذخیره کنید. «حداقل دو هفته» هم قانون جهانی نیست؛ Cycle و Sample هر کسب‌وکار متفاوت است.

SRM: قبل از اثر، سلامت تقسیم نمونه را بسنجید

Sample Ratio Mismatch یعنی نسبت مشاهده‌شده Variantها با نسبت برنامه‌ریزی‌شده سازگار نیست. علت می‌تواند Bucketing، Redirect، Error، Bot filtering، Telemetry، Join یا شرط‌گذاری پس از Treatment باشد. پژوهش Microsoft Research درباره SRM آن را علامت Data-quality جدی می‌داند.

• SRM check را بر Randomization unit و در طول زمان اجرا کنید.
• Ratio را فقط چشمی بررسی نکنید؛ Sample size مهم است.
• تا علت رفع نشده، Lift را مبنای Ship نکنید.
• SRM را در Segment، Browser، Route و Error code عیب‌یابی کنید.

A/A test و Instrumentation rehearsal

A/A دو نسخه ظاهراً یکسان را تقسیم می‌کند تا Assignment، Exposure، Metric، SRM، Variance و False-alert pipeline آزمایش شود. A/A تضمین سلامت آینده نیست، اما پیش از اولین تست مهم یا پس از تغییر Platform، خطاهای بنیادی را آشکار می‌کند. هم‌زمان Test order، Refund، Offline event و Kill switch را تمرین کنید.

Peeking، Multiple comparisons و Segment fishing

اگر هر ساعت نتیجه را نگاه کنید و به‌محض سبزشدن متوقف شوید، روش Frequentist معمولی دیگر وعده خطای اولیه را حفظ نمی‌کند. یا Duration/Sample را از پیش رعایت کنید یا Sequential method معتبری به کار ببرید. همچنین:

• یک Primary metric اصلی تعیین کنید.
• برای Metric/Variantهای متعدد، روش کنترل خطا را تعریف کنید.
• Segmentهای تصمیم را پیش‌ثبت کنید؛ یافته پسینی را Exploratory بنامید.
• Novelty، Learning و Seasonality را با Run کافی و Follow-up بسنجید.
• نتیجه نامعین را به «تقریباً برد» تبدیل نکنید.

خواندن نتیجه: Effect size و بازه عدم‌قطعیت مهم‌تر از برچسب برد است

Profit و Quality: Conversion ارزان می‌تواند کسب‌وکار را گران کند

برای فروشگاه، معیار بهتر ممکن است Contribution margin per eligible user باشد:

Net contribution =
  collected revenue
  - discount
  - payment fee
  - cost of goods
  - shipping subsidy
  - expected refund/return/fraud/support cost

Outcome تأخیری مانند Refund یا Lead quality را با Window روشن Join کنید. اگر تصمیم فوری لازم است، Proxy زودهنگام را با Guardrail و Holdout بلندمدت همراه کنید. برای اقتصاد کانال و سود واقعی، راهنمای بازاریابی فروشگاه بر پایه Profit مرز مالی را تکمیل می‌کند.

Checkout CRO: خطا، اعتماد و عملیات را هم‌زمان ببینید

کاهش Field همیشه Conversion را بالا نمی‌برد؛ شاید داده لازم Fulfillment حذف شود و لغو سفارش بالا رود. در Checkout موارد زیر را به‌عنوان System بررسی کنید:

• قیمت نهایی، هزینه ارسال، زمان تحویل و سیاست مرجوعی پیش از تعهد؛
• Guest checkout یا ثبت‌نام با دلیل روشن؛
• Validation فارسی، شماره موبایل، کد پستی و Error قابل اصلاح؛
• Retry امن درگاه بدون سفارش/پرداخت تکراری؛
• حفظ State بعد از بازگشت از بانک یا قطع اینترنت؛
• روش پرداخت و Fulfillment متناسب با محصول و ریسک.

برای طراحی Stepها و Stateهای تراکنش، راهنمای بهینه‌سازی Checkout را اجرا کنید.

فرم CRO: «تکمیل بیشتر» با «Lead بهتر» فرق دارد

Field کمتر می‌تواند Submit را بالا ببرد و Qualification را پایین بیاورد. Form را با Cost of completion، Error rate، Time، Duplicate/Spam، Contactability، Sales acceptance و Close rate بسنجید. برچسب، Instruction و Error باید قابل‌فهم باشند؛ WCAG ۲.۲ درباره Error Identification می‌خواهد فیلد خطادار و ماهیت خطا با متن مشخص شود.

Performance و Accessibility Guardrail هستند، نه جزئیات پس از تست

Tool آزمایش Client-side می‌تواند Flicker، Layout shift، Script error و LCP بدتر بسازد؛ Popup می‌تواند Focus و Keyboard را بشکند. حداقل Guardrail:

• LCP، INP، CLS و JavaScript error به تفکیک Variant؛
• Keyboard، Focus order، Screen reader name و Zoom؛
• Target size، Error identification و عدم انسداد محتوا؛
• Fallback در Script/CDN failure؛
• SEO برای Content/Link/Structured-data Variant در صورت اثر عمومی.

اگر Treatment دسترس‌پذیری را خراب کند، Lift کوتاه‌مدت مجوز Ship نیست.

شخصی‌سازی: یک Treatment با Holdout، نه «تجربه منحصربه‌فرد» مبهم

Personalization باید بگوید چه Signalی، برای کدام Segment، چه تصمیمی، با چه Fallback و چه Outcomeی استفاده می‌شود. برای معماری جامع‌تر به راهنمای بازاریابی شخصی‌سازی‌شده مراجعه کنید.

AI باید Hypothesis بسازد، نه Evidence جعل کند

AI می‌تواند Interview note را با بازبینی انسان دسته‌بندی، Variant draft تولید یا anomaly را Flag کند. نباید Quote کاربر، علت رفتار یا نتیجه آماری را اختراع کند. برای سیستم‌های تصمیم‌یار/شخصی‌سازی، NIST AI RMF چارچوب Govern/Map/Measure/Manage را برای ریسک و نظارت پیشنهاد می‌کند.

CRO اخلاقی: اعتماد یک Guardrail بلندمدت است

Countdown جعلی، هزینه پنهان، Opt-out دشوار، پیش‌انتخاب رضایت، Confirmshaming و کمیابی ساختگی ممکن است Click کوتاه‌مدت بسازند و شکایت، Refund و ریزش بلندمدت را بالا ببرند. گزارش رسمی FTC درباره Dark patterns نمونه‌هایی مانند پنهان‌کردن هزینه، لغو دشوار و سوق‌دادن کاربر به اشتراک داده را شرح می‌دهد.

برای Pattern و تست اخلاقی، راهنمای طراحی اخلاقی و دارک‌پترن را بخوانید. قانون محل فعالیت و بازار هدف را با مشاور حقوقی بررسی کنید؛ این مقاله مشاوره حقوقی نیست.

وقتی Traffic کم است چه کنیم؟

1. Bug، Error log، Payment failure و Accessibility failure قطعی را رفع کنید.
2. ۵ تا ۸ تست کاربردپذیری هدفمند برای کشف مانع، نه برآورد نرخ، اجرا کنید.
3. Funnel را به Opportunityهای پرExposure محدود کنید.
4. تغییر بزرگ‌تر با Mechanism روشن و Guardrail بسازید؛ Micro-copy بی‌اثر را صف نکنید.
5. Rollout مرحله‌ای، Before/after با کنترل فصل و Cohort را با محدودیت صریح به کار ببرید.
6. داده را میان Channel/Route نامتجانس ادغام نکنید فقط برای Sample بیشتر.
7. نتیجه نامطمئن را به‌عنوان Learning ثبت کنید، نه برد.

B2B و Leadهای چرخه‌بلند: Offline outcome را برگردانید

برای B2B، Form submit Conversion نهایی نیست. Lead باید با CRM، Qualification، جلسه، Proposal، Win، Revenue و Margin Join شود. Window ممکن است چند هفته یا ماه باشد؛ بنابراین:

• Lead ID غیرحساس و منبع/Experiment version را End-to-end حمل کنید.
• Sales acceptance rule و Duplicate merge را نسخه‌دار کنید.
• Lag تا Qualification/Win را در Sample plan لحاظ کنید.
• Proxy زودهنگام را با Outcome دیرهنگام Calibration کنید.
• تیم Sales نباید Variant را انتخاب یا Lead خوب را فقط به یک گروه Route کند.

CRO برای ایران: Failureهای محلی را در قرارداد بیاورید

تغییر هم‌زمان در قیمت، موجودی، کمپین، درگاه یا ارسال را در Experiment log ثبت کنید. «تهران» نماینده کل ایران نیست؛ شهر، اپراتور، دستگاه و مسیر خرید را Segment کنید، اما Segment کم‌نمونه را قطعی گزارش نکنید.

انتخاب ابزار CRO با Capability matrix

یک Pilot با A/A، A/B کم‌خطر، Failure injection، Export و Exit اجرا کنید. نام ابزار از قابلیت قابل‌آزمون مهم‌تر نیست.

معماری Client-side، Server-side و Feature flag

Assignment را مستقل از Analytics vendor نگه دارید تا Telemetry failure Variant delivery را عوض نکند. Experiment ID و Variant باید از Client تا Order/CRM Trace شوند.

RACI و Decision rights

کسی که Variant را می‌سازد نباید به‌تنهایی Metric را عوض، Segment برنده را انتخاب و Ship را تصویب کند. استقلال review متناسب با ریسک باشد.

چرخه هفتگی CRO

1. دوشنبه: Data-quality، Funnel و incident review؛
2. سه‌شنبه: Research synthesis و Problem framing؛
3. چهارشنبه: Hypothesis/contract/stat/privacy review؛
4. پنجشنبه: QA assignment/exposure/events/accessibility/performance؛
5. جمعه/چرخه مناسب تیم: Launch/monitor فقط با On-call و kill switch؛
6. پس از پایان: blind-first analysis، decision record و backlog learning؛
7. ماهانه: Win rate نه؛ Quality، shipped impact، guardrail و debt review.

برنامه ۹۰روزه ساخت سیستم CRO

خطاهای رایج CRO

• بهینه‌کردن Conversion rate بدون Profit، Refund یا Quality؛
• محاسبه نرخ با Session، User و Exposure مخلوط؛
• تکیه بر GA4 page/thank-you بدون Server truth؛
• دیدن Heatmap و اعلام علت روان‌شناختی؛
• اجرای Test بدون Hypothesis، MDE، Power یا Stop rule؛
• تحلیل Lift با SRM یا Telemetry loss؛
• Peeking و توقف وقتی سبز شد؛
• انتخاب Segment برنده پس از نتیجه؛
• شخصی‌سازی AI بدون Holdout، Fallback یا Consent؛
• استفاده از Urgency/Scarcity جعلی و هزینه پنهان؛
• نادیده‌گرفتن Performance، Accessibility و درگاه ایران؛
• خرید ابزار پیش از Metric contract و Exit test.

چک‌لیست قبل از Launch آزمایش

• Question، Owner و Decision rule ثبت شده‌اند.
• Eligibility، Randomization unit، Assignment و Exposure دقیق‌اند.
• Primary/MDE/alpha/power/duration/multiplicity از پیش تعریف شده‌اند.
• Guardrailهای Profit/Refund/Error/CWV/Accessibility/Trust حاضرند.
• Eventها با Server/CRM/Order truth Reconcile شده‌اند.
• A/A/SRM/duplicate/missing/join checks فعال‌اند.
• Consent، Masking، Retention، Vendor و دسترسی review شده‌اند.
• Variant روی Mobile/RTL/Keyboard/Screen reader/Slow network QA شده است.
• Campaign/price/inventory/gateway confounder log فعال است.
• Kill switch، Rollback، On-call و reconciliation آماده‌اند.

پرسش‌های متداول درباره CRO

CRO چیست و چه تفاوتی با افزایش ترافیک دارد؟

CRO با تحقیق و ارزیابی علّی، درصد یا ارزش کاربران واجدی را بهتر می‌کند که Outcome مشخص انجام می‌دهند. افزایش ترافیک Population را بزرگ می‌کند؛ CRO کیفیت مسیر و تجربه را. هر دو باید با Profit، اعتماد و Guardrail سنجیده شوند.

نرخ تبدیل خوب چقدر است؟

Benchmark عمومی پاسخ تصمیم نیست. نرخ به محصول، قیمت، کانال، Intent، Device، تعریف Conversion و مخرج وابسته است. Baseline خودتان را با Cohort همسان مقایسه کنید و به‌جای یک درصد جادویی، Effect اقتصادی و بازه عدم‌قطعیت بسازید.

برای A/B test چقدر ترافیک لازم است؟

عدد ثابت وجود ندارد. Sample به Baseline، MDE، Variance، alpha، power، تعداد Variant/Metric، Unit و Cycle کسب‌وکار وابسته است. پیش از Launch محاسبه کنید؛ اگر Sample لازم در زمان معقول نمی‌رسد، تغییر بزرگ‌تر، Funnel پرExposure یا روش تحقیق دیگری انتخاب کنید.

با ترافیک کم چگونه CRO را شروع کنیم؟

از Event/Server log، خطاهای پرداخت و فرم، Ticket، مصاحبه و تست کاربردپذیری برای یافتن مانع روشن استفاده کنید. Bug و Accessibility failure را رفع، Rollout مرحله‌ای اجرا و محدودیت نتیجه Before/after را صریح کنید. داده ناهمگون را فقط برای Sample بیشتر ادغام نکنید.

نقش هوش مصنوعی در CRO چیست؟

AI می‌تواند Research note را دسته‌بندی، Variant draft بسازد، anomaly را Flag یا Personalization candidate پیشنهاد کند؛ اما Metric، Consent، Causality و تصمیم Ship را جایگزین نمی‌کند. خروجی باید با Evidence، Human review، Holdout، Guardrail، Fallback و Monitoring ارزیابی شود.

جمع‌بندی: نرخ تبدیل را بهتر نکنید؛ تصمیم تبدیل را قابل‌اعتماد کنید

CRO حرفه‌ای با «ایده دکمه» آغاز نمی‌شود؛ با Outcome، Population و Data contract آغاز می‌شود. سپس Research مانع را پیدا می‌کند، Hypothesis سازوکار را توضیح می‌دهد، Experiment اثر علّی را با MDE/Power/SRM/Guardrail می‌سنجد و Profit/Refund/Trust تعیین می‌کنند آیا Ship منطقی است.

ترتیب اجرایی ماندگار این است: Truth → Metric tree → Research → Hypothesis → Pre-register → QA/A/A/SRM → Run → Effect/CI/Guardrail → Profit → Rollout/Holdout → Learn. با این سیستم، حتی نتیجه منفی دارایی دانشی می‌شود و تیم ایرانی از Growth نمایشی به رشد قابل‌دفاع می‌رسد.