ارزش‌گذاری وب‌سایت؛ روش‌ها، Due Diligence و معامله

خریدار یک وب‌سایت، Screenshot ترافیک یا مجموع هزینه طراحی را نمی‌خرد؛ جریان نقدیِ قابل‌انتقال و ریسک‌های همراه آن را می‌خرد. اگر درآمد به حضور روزانه مؤسس وابسته باشد، دامنه به نام شخص دیگری ثبت شده باشد یا ۷۰٪ ورودی از یک صفحه ناپایدار بیاید، عدد سود روی کاغذ به‌تنهایی قیمت را توجیه نمی‌کند. از آن طرف، فروشنده‌ای که حقوق کد، قرارداد مشتری، داده تحلیلی و فرآیندهایش را مستند کرده، دارایی قابل‌بررسی‌تری عرضه می‌کند.

ارزش‌گذاری وب‌سایت یک «ماشین‌حساب آنلاین» یا ضریب ثابت برای همه نیست. ابتدا باید موضوع معامله، تاریخ و مبنای ارزش روشن شود؛ سپس سود/جریان نقدی نرمال، بازار مقایسه‌پذیر، هزینه جایگزینی و ریسک‌های مالی، ترافیکی، فنی، حقوقی و عملیاتی با شواهد بررسی شوند. این راهنما چارچوب Due Diligence و مذاکره می‌دهد، نه توصیه خرید، فروش، مالیاتی یا حقوقی. برای معامله واقعی در ایران، ارزیاب کسب‌وکار، حسابدار و وکیل آشنا با ساختار همان قرارداد باید اسناد را بازبینی کنند.

اول مشخص کنید دقیقاً چه چیزی ارزش‌گذاری می‌شود

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

Scope را در یک «Asset schedule» نسخه‌دار بنویسید: چه چیزی داخل، چه چیزی خارج و انتقال هر مورد مشروط به چه تأییدی است. برای دامنه، راهنمای مالکیت، امنیت و انتقال دامنه را ببینید. سیاست رسمی ICANN برای انتقال دامنه‌های عمومی نیز محدودیت‌ها، قفل‌ها و نقش Registered Name Holder را توضیح می‌دهد؛ دامنه ‎.ir و هر Registry دیگر قواعد خودش را دارد.

ارزش، قیمت، هزینه و ارزش دفتری را یکی نکنید

• ارزش برآوردی: نتیجه یک تحلیل با مبنای ارزش، تاریخ، فرض و روش مشخص؛
• قیمت معامله: مبلغ و شرایطی که طرفین نهایتاً می‌پذیرند؛
• هزینه ساخت: پول و زمان صرف‌شده؛ ممکن است بازار برای آن ارزشی قائل نباشد؛
• ارزش دفتری: عدد حسابداری طبق قواعد شناسایی و استهلاک؛ لزوماً ارزش بازار نیست؛
• قیمت آگهی: خواسته فروشنده، نه شاهد معامله انجام‌شده.

IAS ۳۸ درباره دارایی نامشهود شرایط شناسایی و اندازه‌گیری حسابداری را بیان می‌کند. استفاده از آن برای فهم تفاوت دارایی ثبت‌شده و ارزش اقتصادی مفید است، اما رقم ترازنامه را نباید مستقیم قیمت وب‌سایت دانست.

قرارداد ارزش‌گذاری: شش پاسخ پیش از محاسبه

استانداردهای International Valuation Standards Council بر Scope of work، مبنای ارزش، داده/ورودی، رویکرد، مدل، مستندسازی و گزارش تأکید می‌کنند. نام روش به‌تنهایی تحلیل را معتبر نمی‌کند؛ کیفیت ورودی و افشای محدودیت‌ها تعیین‌کننده است.

سه رویکرد اصلی ارزش‌گذاری وب‌سایت

رویکردهای بازار، درآمد و هزینه سه زاویه‌اند. بسته به بلوغ و مدل سایت، ممکن است یک روش اصلی و روش دیگر Sanity check باشد. اگر دو روش اختلاف زیادی دارند، میانگین‌گیری کور نکنید؛ تفاوت Scope، داده یا فرض را پیدا کنید.

۱. رویکرد درآمد: ارزش جریان نقدی آینده

برای سایت سودده، ابتدا شاخص مالی مناسب را نرمال کنید: SDE برای کسب‌وکاری که مالک‌ـاپراتور آن را می‌خرد، EBITDA برای ساختار مدیریتی مستقل‌تر، یا Free Cash Flow برای DCF. برچسب مهم نیست؛ تعریف دقیق و تطبیق با صورت‌حساب مهم است.

درآمد ثبت‌شده
− Refund و Chargeback
− هزینه مستقیم محصول/خدمت و درگاه/ارسال
− هزینه جذب و نگهداشت ضروری
− حقوق بازارِ نیروی لازم برای ادامه کار
− هاست، نرم‌افزار، پشتیبانی و Compliance
± تعدیلات غیرتکراریِ مستند
= جریان نقدی/سود نرمال‌شده

دو روش رایج در این رویکرد عبارت‌اند از Capitalization/Multiple روی درآمد نرمال‌شده و Discounted Cash Flow. Multiple باید از معاملات واقعاً مقایسه‌پذیر و در بازه زمانی نزدیک استخراج شود؛ عدد ثابت ۲۴ تا ۴۸ برابر سود ماهانه برای همه وب‌سایت‌ها قاعده قابل‌دفاعی نیست.

ارزش DCF = Σ [FCF_t / (1 + r)^t] + [Terminal Value / (1 + r)^n]

در DCF، Forecast، نرخ تنزیل، رشد پایدار، سرمایه در گردش، CAPEX و مالیات باید با هم سازگار باشند. رشد اسمی را با نرخ تنزیل واقعی یا برعکس مخلوط نکنید. به‌جای یک نقطه، Base/Downside/Upside و حساسیت به Conversion، Margin، Churn، CAC و ترافیک ارگانیک بسازید.

۲. رویکرد بازار: مقایسه معامله‌های مشابه

Comparable باید در مدل درآمد، اندازه، Margin، رشد، سن، کانال جذب، تمرکز مشتری، جغرافیا، میزان دخالت مالک و ساختار معامله شبیه باشد. قیمت آگهی با قیمت Closing برابر نیست؛ Earn-out، Seller financing، Working capital و دارایی‌های داخل معامله می‌توانند Multiple ظاهری را تغییر دهند.

۳. رویکرد هزینه: بازسازی دارایی با مطلوبیت مشابه

برای سایت پیش‌درآمد، ابزار داخلی یا مجموعه محتوای خاص، هزینه جایگزینی تعدیل‌شده می‌تواند قرینه‌ای باشد: Discovery، طراحی، کد، محتوا، داده، QA، SEO migration و زمان رسیدن به وضعیت عملیاتی منهای Obsolescence و بدهی فنی. هزینه تاریخیِ بد صرف‌شده ارزش نمی‌آفریند و زمان ساخت نیز معادل دستیابی به همان اعتماد، مشتری یا رتبه نیست.

برای برآورد هزینه زیرساخت و تمدید، از مدل TCO دامنه و هاست استفاده کنید؛ اما TCO فقط یک جزء از اقتصاد کسب‌وکار است.

مثال عددی: محاسبه سناریو، نه صدور قیمت

فرض کنید یک سایت خدماتی در ۱۲ ماه گذشته ۹ میلیارد ریال وصول، ۱٫۲ میلیارد Refund و ۴٫۸ میلیارد هزینه ضروری داشته است. فروشنده ۱٫۲ میلیارد «سود شخصی» گزارش کرده که بخشی از آن ناشی از کار بدون حقوق خود اوست. اگر جایگزینی نقش او سالانه ۹۰۰ میلیون ریال هزینه داشته باشد، سود نرمال‌شده باید آن را لحاظ کند.

وصول:                         9.0 میلیارد ریال
− Refund:                     1.2
− هزینه عملیاتی ضروری:        4.8
− حقوق بازار نقش مؤسس:        0.9
= جریان نرمال پیش از مالیات:  2.1 میلیارد ریال

حالا تحلیلگر Multiple را از معاملات مقایسه‌پذیر استخراج و به‌دلیل تمرکز ۵۵٪ درآمد روی دو مشتری، بدهی فنی و قراردادهای قابل فسخ تعدیل می‌کند. این مثال عمداً Multiple و «قیمت نهایی» نمی‌دهد؛ چون بدون بازار مقایسه، ساختار معامله، مالیات و ریسک حقوقی، عدد ساختگی حس دقت کاذب ایجاد می‌کند.

کیفیت درآمد: از Dashboard تا Bank reconciliation

Revenue داخل Analytics یا پنل فروش، پول قطعی نیست. سفارش، پرداخت، Settlement بانکی، Refund، Chargeback، لغو، مالیات، تخفیف، ارسال و هزینه کالای فروش‌رفته را برای دست‌کم ۱۲ تا ۲۴ ماه Reconcile کنید. فصل‌ها، کمپین‌ها و تغییر قیمت را علامت بزنید.

Add-back را سخت‌گیرانه بررسی کنید

هزینه شخصیِ واقعاً غیرعملیاتی یا رویداد یک‌باره ممکن است Add-back شود؛ هزینه‌ای که خریدار برای حفظ درآمد باید ادامه دهد، Add-back نیست. هر تعدیل باید مبلغ، دوره، سند، علت و احتمال تکرار داشته باشد. حقوق پایین مؤسس، تبلیغ قطع‌شدنی که ورودی می‌سازد و توسعه به‌تعویق‌افتاده معمولاً نیازمند Normalization رو به پایین‌اند.

درآمد تکرارشونده و Cohort را درست بخوانید

در Subscription، MRR اسمی بدون Churn، Expansion، تخفیف سالانه، وصول ناموفق و هزینه خدمت کافی نیست. Customer cohort را بر اساس ماه شروع دنبال کنید و Gross revenue retention، Net revenue retention، Logo churn، ARPA و Contribution را با تعریف ثابت بسنجید. راهنمای مدل کسب‌وکار اشتراکی و Unit Economics تعریف و کنترل این سنجه‌ها را تکمیل می‌کند.

برای Ecommerce، مشتری بازگشتی، نرخ Refund/Return، Cancel، AOV، Margin پس از ارسال و CAC را در Cohort ببینید. رشد ناشی از تخفیف سنگین ممکن است درآمد را بالا و ارزش اقتصادی را پایین ببرد.

اعتبارسنجی ترافیک: یک منبع کافی نیست

حداقل GA4، Search Console، Server/CDN log، پنل تبلیغات و داده سفارش را مثلث‌بندی کنید. تعریف User، Session، Click و Order در ابزارها یکسان نیست. اختلاف لزوماً تقلب نیست، اما باید توضیح‌پذیر باشد.

راهنمای رسمی GA4 Traffic acquisition Scopeهای منبع جلسه را توضیح می‌دهد و مستند GA4 Data thresholds نشان می‌دهد برخی داده‌ها ممکن است برای حریم خصوصی نمایش داده نشوند. در Search Console نیز همه Queryها نمایش داده نمی‌شوند و داده عمدتاً به Canonical نسبت داده می‌شود؛ این محدودیت‌ها در مستند Performance report گوگل آمده است.

برای ساخت Measurement contract و Reconciliation، راهنمای تحلیل داده‌های بازاریابی را به Data room وصل کنید.

سئو: ترافیک ارگانیک دارایی مستقل و تضمینی نیست

Domain Authority متریک شخص ثالث است، نه امتیاز رسمی گوگل و نه قیمت. ارزش اقتصادی SEO از Query/صفحه‌ای می‌آید که مخاطب واجد شرایط و نتیجه مالی قابل حفظ می‌سازد. Top pages، Intent، Brand dependence، Conversion، محتوا و لینک را بررسی کنید.

چک‌لیست ریسک سئو

• تغییر Click/Impression به تفکیک Page، Query، Device و Country در ۱۶ ماه موجود؛
• Manual action، Security issue، Index coverage، Canonical و Sitemap؛
• تمرکز ترافیک روی چند صفحه، نویسنده یا Topic؛
• منشأ لینک، Anchor، Link spike، شبکه سایت و قرارداد خرید لینک؛
• اصالت و حق انتشار محتوا، AI workflow و امکان Refresh توسط خریدار؛
• وابستگی Conversion به رتبه‌ای که در دوره Due Diligence افت کرده است.

چک‌لیست ممیزی کامل سئو را روی Staging یا نسخه Read-only اجرا کنید و یافته را به اثر مالی وصل کنید؛ تعداد خطا بدون Materiality به تصمیم خرید کمک نمی‌کند.

برند و جامعه: شواهد اعتماد را از Vanity جدا کنید

Follower و Email count به‌تنهایی ارزش نیست. Deliverability، Consent، Engagement، Repeat purchase، Direct/branded demand، Complaint، Review authenticity و وابستگی جامعه به چهره مؤسس مهم‌اند. اگر مخاطب فقط با شخص فروشنده رابطه دارد، انتقال برند ممکن است Churn بسازد.

Brand asset باید قابلیت انتقال حقوقی و عملی داشته باشد: نام و نشان، Design source، Tone/Guideline، قرارداد Creator، مجوز رسانه و تاریخچه Reputation. معماری شواهد و Trust journey را نیز ارزیابی کنید؛ ادعای برند باید به مدرک، مالک و تاریخ اعتبار متصل باشد.

ممیزی فنی: ارزش کد برابر خط‌های کد نیست

کد بیشتر ممکن است بدهی بیشتر باشد. Architecture، Test، Deployment، Dependency، License، Performance، Security، Data model، Backup و Bus factor را بررسی کنید. خریدار باید بتواند Build را از Repository تمیز تکرار کند، محیط را بدون Secret فروشنده بالا بیاورد و Release/Rollback را در حضور خود اجرا کند.

هزینه Remediation را از کشف تا آزمون و فرصت ازدست‌رفته مدل کنید، نه فقط ساعت برنامه‌نویس. برای طبقه‌بندی Principal/Interest و Roadmap، راهنمای مدیریت بدهی فنی را ببینید.

امنیت و حریم خصوصی: ریسک گذشته هم منتقل می‌شود

Asset inventory، Data flow، رده داده، Admin account، MFA، Secret، Patch، Vulnerability، Incident، Backup و Subprocessor را بررسی کنید. نبود رخداد گزارش‌شده معادل نبود رخداد نیست؛ ببینید Logging و Detection اساساً قادر به مشاهده بوده‌اند یا نه.

• چه داده شخصی یا پرداختی جمع می‌شود و مبنای نگهداری/اشتراک چیست؟
• آیا Consent، Unsubscribe، حذف و Retention اجرا و قابل اثبات‌اند؟
• آیا رخداد، باج‌افزار، Leak یا شکایت حل‌نشده وجود دارد؟
• Backup مستقل و Restore drill موفق با تاریخ و نتیجه کجاست؟
• در Closing چه Credentialهایی Rotate و چه دسترسی‌هایی Revoke می‌شوند؟

سناریوی زیان و کنترل را با مدل هزینه نقض داده کمی کنید. برای داده حساس یا معامله سهام، مشاور حقوقی باید تعهد افشا، مسئولیت رخداد قبلی و Indemnity را متناسب با قانون و قرارداد بررسی کند.

وابستگی عملیاتی: اگر مؤسس برود چه می‌ماند؟

یک هفته کار را Observation کنید و Time log بگیرید: فروش، محتوا، پشتیبانی، تأمین، قیمت‌گذاری، Refund، Incident و رابطه مشتری. سپس هر فعالیت را به Role، زمان، Skill، SOP، دسترسی و هزینه جایگزین وصل کنید.

Data room: مدرک خوب چه شکلی است؟

Data room باید Read-only، سطح‌بندی‌شده، زمان‌دار و دارای Log باشد. PII و Secret را پیش از نیاز افشا نکنید؛ داده نمونه/Redacted برای مرحله اولیه کافی است. فروشنده یک Index با مالک، دوره، تاریخ به‌روزرسانی و وضعیت راستی‌آزمایی بسازد.

فهرست پیشنهادی پوشه‌ها

1. Scope/Ownership: شرکت، دارایی، دامنه، IP و قراردادها؛
2. Financial: P&L ماهانه، Bank/gateway reconciliation، Tax و Working capital؛
3. Customer/Revenue: قرارداد، Cohort، Churn، Concentration و Pipeline؛
4. Traffic/SEO: GA4، Search Console، Log، Ads، content/link inventory؛
5. Technology: Architecture، Repo، SBOM، Debt، incidents و DR؛
6. Security/Privacy: Data map، IAM، Assessment، consent و subprocessor؛
7. Operations/People: SOP، RACI، vendor، key person و support load؛
8. Forecast/Valuation: Assumption، scenario، comparable و sensitivity؛

evidence_record = {
  "metric": "normalized_monthly_contribution",
  "period": "1404-05..1405-04",
  "source": ["orders", "gateway_settlement", "refunds", "bank"],
  "owner": "finance",
  "reconciled_at": "1405-05-20",
  "exceptions": ["gateway_batch-184 pending"],
  "reviewer": "independent-accountant"
}

Red flagها را به اثر و درمان وصل کنید

Red flag الزاماً پایان معامله نیست؛ اما نباید فقط با Multiple پایین‌تر «حل» شود. بعضی موارد شرط پیش از Closing، بعضی تغییر ساختار و بعضی Deal breaker هستند.

ساختار معامله چگونه ریسک را تقسیم می‌کند؟

• Cash at close: ساده‌تر، اما ریسک Forecast بیشتر با خریدار؛
• Holdback/Escrow: بخشی برای Claims یا انتقال موفق نگه داشته می‌شود؛
• Earn-out: مبلغ به Revenue/Contribution/Retention آینده وابسته می‌شود؛ تعریف Metric و کنترل طرفین حیاتی است؛
• Seller financing: پرداخت زمان‌بندی‌شده با ریسک اعتباری و وثیقه؛
• Transition services: حضور محدود فروشنده با Deliverable، زمان و Exit روشن؛
• Asset vs share deal: دامنه مسئولیت، مالیات، قرارداد و مجوزها متفاوت است.

Earn-out مبهم اختلاف می‌سازد. Revenue ناخالص یا Contribution؟ Refund و تخفیف چگونه حساب می‌شود؟ خریدار چقدر بودجه تبلیغ را کنترل می‌کند؟ دسترسی گزارش، زمان تسویه، سقف، کف و حل اختلاف باید دقیق باشند.

Closing و انتقال: لحظه پرریسک معامله

انتقال را مثل یک Migration طراحی کنید، نه ارسال Password در پیام‌رسان. Inventory، Owner، ترتیب، Dependency، Acceptance test، Rollback و Hypercare لازم‌اند. راهنمای مهاجرت پلتفرم با Reconciliation الگوی مناسبی برای Cutover فنی می‌دهد.

1. نسخه پشتیبان مستقل، Export و Checksum بگیرید و Restore نمونه را انجام دهید.
2. دامنه، DNS، CDN، Hosting، Repo، CI، App store، Analytics و Support را طبق Runbook منتقل کنید.
3. Adminهای خریدار را بسازید؛ سپس Credential/Key/Token قبلی را Rotate و دسترسی فروشنده را Revoke کنید.
4. مالکیت Search Console، Analytics، Email، Merchant و شبکه‌ها را طبق Policy هر سرویس تأیید کنید.
5. Order/Customer/Subscription/Consent count و مجموع‌های مالی را پیش و پس از Cutover تطبیق دهید.
6. Acceptance criteria را امضا و دوره Hypercare و مسئول Incident را فعال کنید.

ملاحظات ارزش‌گذاری و معامله در ایران

اعداد ریالی/تومانی، تورم و ارز می‌توانند مقایسه را منحرف کنند. واحد، تاریخ نرخ تبدیل و اسمی/واقعی بودن Forecast را ثبت کنید. Revenue ارزی را بدون بررسی قابلیت وصول، KYC، محدودیت حساب و هزینه تبدیل، هم‌ارز پول نقد داخلی نگیرید.

• مالکیت دامنه ‎.ir، شناسه ایرنیک، رابط‌ها و دسترسی ایمیل بازیابی را در حضور طرفین آزمون کنید.
• قابلیت انتقال درگاه، نماد/مجوز، پنل پیامک، مارکت‌پلیس، شبکه اجتماعی و ابزار خارجی را از Provider بپرسید.
• پرداخت خارجی، ریسک تعلیق، تمدید License و حساب‌های ساخته‌شده با هویت واسطه را افشا کنید.
• IRR و تومان را در Schema و گزارش جدا کنید؛ خطای ۱۰برابری را با Reconciliation ماشینی بگیرید.
• تعهدات مالیاتی، بیمه‌ای، مصرف‌کننده، حریم خصوصی، کارکنان و مالکیت فکری را متخصص محلی بررسی کند.
• سناریوی قطع دسترسی سرویس خارجی، Export داده و زمان/هزینه جایگزینی را در Downside قرار دهید.

فروشنده چگونه طی ۶۰ روز قابلیت بررسی را بالا ببرد؟

روز ۱ تا ۲۰: حقیقت و Scope

• Asset schedule، مالکیت، قرارداد و حساب‌ها را Inventory کنید.
• ۲۴ ماه Order/Payment/Bank/Refund/Cost را Reconcile کنید.
• Metric dictionary و Add-back register بسازید.

روز ۲۱ تا ۴۰: ریسک و عملیات

• SEO/Traffic، Security، License، Technical debt و Restore را مستقل بررسی کنید.
• SOP و RACI بسازید و یک هفته Shadow operation بدون مؤسس اجرا کنید.
• Top customer/vendor/platform risk و درمان را مستند کنید.

روز ۴۱ تا ۶۰: مدل و انتقال

• Base/Downside/Upside، Sensitivity و منبع Comparable را آماده کنید.
• Data room سطح‌بندی‌شده و Q&A log بسازید.
• Runbook Closing، Rotation، Reconciliation، Acceptance و Hypercare را تمرین کنید.

خریدار چگونه تصمیم Go، Reprice یا Stop بگیرد؟

سؤال‌های متداول

ساده‌ترین فرمول ارزش‌گذاری وب‌سایت چیست؟

فرمول واحد و معتبر برای همه سایت‌ها وجود ندارد. Multiple روی سود/جریان نقدی نرمال‌شده می‌تواند نقطه شروع باشد، اما Multiple باید از معاملات مقایسه‌پذیر و با تعدیل رشد، تمرکز، انتقال‌پذیری و ریسک استخراج شود. روش بازار، درآمد و هزینه را با Scope و تاریخ یکسان مقایسه کنید.

آیا هزینه طراحی و تولید محتوا قیمت سایت را تعیین می‌کند؟

خیر. هزینه جایگزینی یک قرینه است، به‌ویژه برای دارایی پیش‌درآمد، اما هزینه تاریخی ممکن است ناکارا یا منسوخ باشد. جریان نقدی، حقوق قابل انتقال، زمان بازسازی، کیفیت فنی، بازار و ریسک تعیین می‌کنند خریدار چه ارزشی می‌بیند.

برای اثبات ترافیک وب‌سایت چه مدارکی لازم است؟

دسترسی Read-only به GA4 و Search Console، Export دوره‌ای، Server/CDN log، داده تبلیغات و اتصال Landing به Order/Settlement را مثلث‌بندی کنید. محدودیت Scope، Consent، Threshold، Bot filtering، تغییر Tracking و تمرکز صفحات/منابع را نیز ثبت کنید.

Domain Authority بالا یعنی سایت گران‌تر است؟

نه به‌تنهایی. Domain Authority متریک یک ابزار ثالث است. ارزش SEO به ترافیک واجد شرایط، درآمد قابل حفظ، Intent، تمرکز صفحه/Query، کیفیت محتوا و لینک، تاریخچه امنیت/Manual action و توان خریدار برای نگهداری آن بستگی دارد.

مهم‌ترین Red flag خرید سایت چیست؟

نبود مالکیت یا انتقال‌پذیری روشن برای دارایی کلیدی—دامنه، کد، IP، قرارداد یا حساب—از جدی‌ترین موارد است. درآمد تأییدنشده، وابستگی شدید به مؤسس/یک کانال و نبود Restore نیز می‌توانند Deal breaker باشند. شدت هر مورد به Scope و امکان درمان قراردادی بستگی دارد.

جمع‌بندی

ارزش‌گذاری وب‌سایت از تعریف دقیق دارایی شروع می‌شود، نه از انتخاب ضریب. جریان نقدی را با Bank/Order/Refund نرمال کنید، روش درآمد را با بازار و هزینه Cross-check کنید و کیفیت ترافیک، SEO، برند، کد، امنیت، قرارداد و عملیات را در Forecast و ساختار معامله منعکس کنید. قیمت خوب فقط عدد مناسب نیست؛ انتقالی است که مالکیت، داده، دسترسی، مسئولیت و معیار پذیرش آن قابل اثبات باشد.

منابع منتخب

• IVSC — International Valuation Standards
• IFRS Foundation — IAS 38 Intangible Assets
• Google Analytics — Traffic acquisition report
• Google Analytics — Data thresholds
• Google Search Console — Performance report data
• ICANN — Transfer Policy