کاربر روی تبلیغ «دموی ۲۰ دقیقهای نرمافزار حسابداری فروشگاهی» کلیک میکند، اما به صفحهای میرسد که از تاریخچه شرکت، ده خدمت و یک فرم «تماس با ما» حرف میزند. مشکل رنگ دکمه نیست؛ زنجیره وعده شکسته است. لندینگ پیج صفحهای است که برای یک زمینه ورود، مخاطب، پیشنهاد و اقدام تعریفشده ساخته میشود و باید نتیجه آن تا Lead، سفارش یا فعالسازی قابل ردیابی باشد.
یک صفحه فرود خوب الزاماً کوتاه، بدون منو یا دارای یک دکمه نیست. طول، مسیرهای کمکی و حتی نوع تبدیل به مرحله تصمیم و ریسک خرید وابستهاند. این راهنما طراحی لندینگ پیج را از Brief و Message match تا فرم، اعتماد، دسترسپذیری، سرعت، GA4، سئو و A/B تست به یک فرایند قابلممیزی تبدیل میکند؛ با مثالهای فرضی برای کسبوکار ایرانی و بدون وعده افزایش قطعی نرخ تبدیل.
لندینگ پیج چیست؟
Landing page هر صفحهای است که کاربر پس از کلیک یا اسکن یک ورودی مشخص به آن میرسد؛ اما در بازاریابی معمولاً صفحهای اختصاصی برای پیشبرد یک اقدام در یک Stage است. طبق تعریف رسمی Landing page در Google Ads، این صفحه همان مقصد Final URL تبلیغ است. این تعریف فنی بهتنهایی کافی نیست؛ برای طراحی باید Context کاربر، وعده منبع، Offer، شواهد و قدم بعدی نیز ثبت شوند.
هدف لندینگ «وادار کردن همه به کلیک» نیست. باید به فرد مناسب کمک کند تصمیم درست بگیرد و فرد نامناسب را بدون فریب فیلتر کند. برای یک Download کمریسک، دریافت ایمیل ممکن است کافی باشد؛ برای خرید تجهیز صنعتی، تبدیل اصلی شاید درخواست ارزیابی با مشخصات پروژه باشد، نه پرداخت فوری.
| نوع صفحه | وظیفه اصلی | مسیرها | Metric غالب | اشتباه رایج |
|---|---|---|---|---|
| صفحه اصلی | معرفی چند مخاطب و Capability | چندگانه | Discovery و مسیر بعد | فرستادن همه کمپینها به Home |
| صفحه خدمت | پوشش تقاضای پایدار یک خدمت | اصلی + مسیرهای اطلاعاتی | Qualified inquiry و Organic demand | کپی عمومی بدون Qualification |
| لندینگ کمپین | ادامه یک Promise برای Audience مشخص | متمرکز و کنترلشده | Qualified outcome و Unit economics | بهینهسازی فقط Form submit |
| صفحه محصول | ارزیابی SKU، Variant و معامله | محصول/سبد/اطلاعات | Add-to-cart، Order، Margin، Return | حذف اطلاعات تصمیم به نام تمرکز |
| Microsite/Event | روایت یا Journey چندمرحلهای | چند صفحه محدود | Registration/Participation | ساخت سامانه جدا بدون مالکیت |
| صفحه تشکر | تأیید و تعیین قدم بعد | محدود | Completion و Next-step rate | شمارش Page view بهعنوان Conversion |
لندینگ را از اقتصاد و Outcome شروع کنید
پیش از Wireframe یک Landing brief یکصفحهای بسازید. اگر تیم بر سر Outcome توافق ندارد، طراح ناچار است با Patternهای عمومی جای خالی را پر کند. Brief باید تصمیمی باشد که Marketing، Product، Sales، Data و Legal بتوانند بررسی کنند.
Landing brief چه دارد؟
- Source و Campaign ID: Search، Social، Email، Referral، QR یا Organic؛
- Audience و Stage: چه کسی، با چه Trigger و چه میزان آگاهی؟
- Job/Question: کاربر اکنون چه تصمیمی میگیرد؟
- Promise و Offer: چه Outcome و Exchange مشخصی ارائه میشود؟
- Primary action: دقیقاً چه رفتار معتبر و قابل برگشتی Conversion است؟
- Evidence و Objection: کدام ادعا به چه مدرکی نیاز دارد؟
- Qualification: چه فردی مناسب نیست یا نیاز به مسیر دیگری دارد؟
- Economics: سقف CAC/CPL، Margin، ظرفیت پاسخ و Refund/Cancel؛
- Owner/Expiry: مالک محتوا، داده، عملیات و تاریخ پایان کمپین.
Conversion را دقیق نامگذاری کنید
«تبدیل» میتواند CTA click، Form start، Form submit، Lead معتبر، رزرو حاضرشده، پرداخت موفق یا سفارش پس از Refund window باشد. اینها همارز نیستند. فرمول پایه را با مخرج واجد شرایط تعریف کنید:
Landing conversion rate = Valid primary outcomes ÷ Eligible landing views
Landing view را با Ad click یکی نگیرید. Redirect، قطع شبکه، In-app browser، Consent، خطای Script یا Load کند میتواند Click را قبل از مشاهده قابل استفاده صفحه از دست بدهد. برای B2B، Qualified lead rate = Accepted leads ÷ Eligible landing views اغلب از Submit rate مهمتر است.
اقتصاد سربهسر
اگر Contribution margin مورد انتظار هر مشتری ۲۰ میلیون تومان، نرخ Lead→Customer ده درصد و نرخ Landing→Qualified lead پنج درصد باشد، ارزش مورد انتظار هر Landing view پیش از هزینه عملیات تقریباً ۱۰۰ هزار تومان است. این عدد مثال فرضی است، نه Benchmark. Refund، No-show، زمان فروش و هزینه پشتیبانی میتواند آن را کم کند.
| سطح | تعریف نمونه | فرمول | Guardrail |
|---|---|---|---|
| Delivery | Click تا Landing view | Landing views ÷ Outbound clicks | خطا، Latency، Redirect loss |
| Interaction | CTA/Form start | Starts ÷ Eligible views | کلیک تصادفی، Bot |
| Completion | Submit معتبر | Valid submits ÷ Starts | Spam، Duplicate، Error |
| Qualification | Lead پذیرفتهشده | Accepted leads ÷ Valid submits | تعریف Sales و SLA |
| Outcome | Order/Activation | Outcomes ÷ Accepted leads | Cancel، Refund، Fraud |
| Economics | سود افزایشی | Incremental margin − TCO | Attribution و Capacity |
Audience و Stage را با Evidence بشناسید
Persona بر پایه سن و جنسیت بهتنهایی متن نمیسازد. برای لندینگ باید Trigger، Alternative، Risk، معیار تصمیم، زبان واقعی و مانع عملی را پیدا کنید. از Query و Search term، گفتوگوی فروش، Ticket پشتیبانی، Review، Survey کوتاه، Session replay با رعایت حریم خصوصی و داده CRM استفاده کنید.
پنج سؤال تحقیق
- کاربر قبل از ورود چه چیزی دیده یا جستوجو کرده است؟
- برای انجام چه کاری و در چه Deadline آمده است؟
- چه Alternativeای دارد: هیچکاری، Excel، رقیب، تماس تلفنی یا ساخت داخلی؟
- کدام ریسک تصمیم را عقب میاندازد: قیمت، زمان، سازگاری، اعتماد، آموزش یا بازگشت؟
- چه مدرکی برای این ریسک معتبر است و چه کسی میتواند ادعا را تأیید کند؟
Stage طول صفحه را تعیین میکند، نه یک نسخه عمومی
مخاطب Problem-aware ممکن است به آموزش و Diagnostic نیاز داشته باشد؛ فرد Solution-aware مقایسه روش، هزینه و محدودیت میخواهد؛ Product-aware به Evidence، Fit، Risk reversal و قدم معامله نیاز دارد. ترافیک Retargeting لزوماً «گرم» نیست و متن کوتاهتر همیشه بهتر نیست. برای Journey فروشگاه، مرز لندینگ با Product/Cart/Checkout را در راهنمای UX فروشگاه اینترنتی ببینید.
| Stage | پرسش غالب | محتوای لازم | CTA نمونه |
|---|---|---|---|
| Unaware/Problem-aware | مسئله چیست و چرا مهم است؟ | نشانه، Cost of inaction، راههای حل | ارزیابی/راهنما |
| Solution-aware | کدام رویکرد مناسب من است؟ | مقایسه، Trade-off، Fit و Case | مشاهده روش/دمو |
| Product-aware | چرا این گزینه و آیا قابل اعتماد است؟ | Capability، Evidence، Price logic، FAQ | رزرو/استعلام |
| Ready | چگونه بدون ریسک شروع کنم؟ | شرایط، زمان، روش پرداخت، حریم خصوصی | خرید/ثبت نهایی |
| Existing customer | قدم بعد یا Upgrade چیست؟ | Eligibility، Migration، Account context | فعالسازی/ارتقا |
Message match؛ وعده منبع را ادامه دهید
Message match فقط تکرار Keyword در H1 نیست. Offer، Audience، Price condition، Geography، Deadline و Visual cue باید با منبع همراستا باشند. اگر تبلیغ «نسخه آزمایشی بدون کارت بانکی» میگوید، لندینگ نباید ناگهان اطلاعات پرداخت بخواهد. اگر پست Social یک Template رایگان وعده میدهد، صفحه نباید کاربر را به تماس فروش مجبور کند.
Message map
| لایه | سؤال | Artifact | QA |
|---|---|---|---|
| Source | چه Hook/Query/Creativeای دیده شد؟ | Ad/Email/Post ID و Screenshot | نسخه و تاریخ |
| Promise | چه Outcome وعده داده شد؟ | یک جمله با Boundary | Claim ledger |
| Offer | کاربر چه چیزی در برابر چه چیزی میگیرد؟ | Deliverable، زمان، شرط | واقعاً قابل تحویل؟ |
| Evidence | چرا باید باور کند؟ | Demo، Sample، Method، Case | Source/Owner/Date |
| Action | قدم بعد چیست؟ | CTA و Form/Checkout | Destination و Error |
| Outcome | پس از اقدام چه میشود؟ | Confirmation، SLA، Handoff | Backend status |
یک CTA به معنی یک لینک نیست
یک Primary action میتواند در چند نقطه تکرار شود. لینک حریم خصوصی، شرایط، جزئیات روش، نمونه و دسترسپذیری رقیب CTA نیستند؛ آنها ریسک را کم میکنند. منو را وقتی حذف یا محدود کنید که مسیرهایش تصمیم را منحرف میکنند، اما هویت کسبوکار، تماس، سیاست و اطلاعات ضروری را پنهان نکنید. برای کاربر با نیاز متفاوت، Secondary path مانند «ابتدا نمونه را ببینید» ممکن است Conversion آینده را بهتر کند.
Offer را پیش از Copy طراحی کنید
لندینگ نمیتواند Offer مبهم را با تیتر نجات دهد. Offer specification باید Deliverable، Audience fit، Time-to-value، Price/Exchange، Limit، Availability، Support و Risk reversal را روشن کند. تخفیف دائمی، Countdown ساختگی و ظرفیت جعلی اعتماد را میسوزانند.
Offer ladder
برای خرید پرریسک، پرش مستقیم از آشنایی به قرارداد ممکن است بزرگ باشد. نردبان میتواند از Calculator یا Sample به Diagnostic، Demo، Proposal و خرید برسد. هر مرحله داده و تعهد متناسب میگیرد. Lead magnet بیارتباط شاید CPL را کم کند اما صف فروش را پر از Lead نامناسب میکند.
قیمت را پنهان کنیم؟
نسخه عمومی وجود ندارد. در محصول استاندارد، قیمت/هزینه ارسال/شرط بازگشت بخش تصمیماند. در پروژه سفارشی، Range یا Price driver میتواند Self-qualification بسازد. اگر قیمت پس از Discovery تعیین میشود، فرآیند و زمان Quote را شفاف کنید. «برای قیمت تماس بگیرید» بدون منطق، اصطکاک و عدمقطعیت ایجاد میکند.
معماری محتوای لندینگ پیج
ترتیب بلوکها پاسخ به سؤال بعدی کاربر است، نه Template ثابت. Hero باید هویت، Outcome، Audience/Boundary، Evidence سریع و قدم بعدی را با حداقل بار شناختی منتقل کند. همه جزئیات لازم نیست Above the fold باشند؛ اما نباید کاربر برای فهمیدن موضوع صفحه Scroll کند.
| بلوک | وظیفه | Evidence/Content | شرط حذف |
|---|---|---|---|
| Hero | Orientation و Promise | H1 روشن، Subhead، CTA، Qualifier | حذف نمیشود؛ میتواند فشرده باشد |
| Problem/Trigger | تأیید Context | نشانه و Cost واقعی | مخاطب کاملاً Product-aware |
| Outcome/Mechanism | توضیح چگونه | ۳–۵ Outcome با Mechanism | Offer بسیار ساده/شناختهشده |
| Fit/Not fit | Qualification | شرایط، پیشنیاز و محدودیت | بهندرت |
| Evidence | کاهش ریسک باور | Demo، Sample، Method، Case | ادعای کمریسک و قابل مشاهده |
| Process | کاهش ریسک اجرا | قدم، Timeline، Owner | اقدام آنی و ساده |
| Price/Terms | کاهش عدمقطعیت معامله | قیمت، Tax، Renewal، Cancellation | اگر واقعاً در Stage دیگری است |
| Objection/FAQ | حل مانع مهم | پاسخ دقیق با Link/Policy | اگر قبلاً در Context حل شده |
| Form/CTA | اجرای قدم بعد | Expectation، Privacy، Error | برای لندینگ اطلاعاتی بدون تبدیل مستقیم |
Visual باید کار انجام دهد
Screenshot واقعی، نمونه خروجی، Diagram فرایند یا تصویر کاربرد محصول میتواند Evidence باشد. تصویر Stock تزئینی که فقط فضا میگیرد، هزینه دانلود و حواسپرتی میسازد. Caption، Crop موبایل، Alt، حقوق استفاده و تاریخ Freshness را در Asset inventory ثبت کنید.
Copy لندینگ؛ واضح، مشخص و قابلاثبات
فرمول تیتر
فرمول جادویی وجود ندارد، اما یک Draft خوب میتواند «Outcome مشخص + Audience/Context + Boundary» باشد. مثال فرضی: «گزارش روزانه موجودی ۳ شعبه را بدون ادغام دستی فایلها ببینید» از «کسبوکارتان را متحول کنید» قابل ارزیابیتر است. تیتر نباید بیش از Evidence وعده دهد.
Feature را به Mechanism و Outcome وصل کنید
به جای «داشبورد هوشمند»، بنویسید کدام داده با چه تأخیری یکپارچه میشود و چه تصمیمی را آسان میکند. زنجیره Feature → Mechanism → Outcome → Boundary → Evidence جلوی ادعاهای کلی را میگیرد. «Real-time» باید Latency مشخص داشته باشد؛ «امن» باید کنترل و Scope داشته باشد.
Objection را پنهان نکنید
نیاز به آموزش، حداقل سفارش، ناسازگاری، زمان استقرار، هزینه تمدید و چیزی که Included نیست را نزدیک تصمیم بنویسید. این اطلاعات ممکن است Submit خام را کم کند اما Qualification و اعتماد را بهتر کند. برای ساخت شواهد و Claim ledger، از چارچوب اعتماد و E‑E‑A‑T مبتنی بر شواهد استفاده کنید.
اعتماد و Social proof بدون فریب
Logo wall بدون اجازه، Testimonial بینام و عدد بدون روش Trust signal نیستند. Evidence را نزدیک همان Claim قرار دهید و منشأ، بازه، نمونه، نقش شما و Limit را بنویسید. Case study باید Baseline، Intervention، Outcome، Attribution limit و رضایت مشتری برای انتشار داشته باشد.
| ادعا | شاهد مناسب | شاهد ضعیف | کنترل |
|---|---|---|---|
| محصول کار میکند | Demo/Sample قابل مشاهده | عکس تزئینی | نسخه و تاریخ |
| تجربه مرتبط داریم | Case با Method و Scope | لوگو بدون توضیح | رضایت و نقش دقیق |
| کاربر راضی است | نظر واقعی و قابلردیابی | نقلقول ساختگی/گزینشی | Source و ارتباط مادی |
| ریسک معامله کم است | شرایط بازگشت/لغو روشن | Badge «۱۰۰٪ تضمینی» | Policy عملیاتی |
| داده امن است | کنترل، Scope و مسئول | آیکون قفل | Security/Privacy review |
راهنمای جاری FTC درباره Endorsement و Review نیز بر نظر واقعی و افشای ارتباط مادی تأکید دارد. این سند قانون ایران نیست، اما Benchmark مفیدی برای Governance بینالمللی و کمپین فرامرزی است. ادعاها و Testimonialهای لندینگ را با قانون و بازار هدف خودتان بررسی کنید.
فرم لندینگ؛ کوتاهترین فرم همیشه بهترین نیست
هر فیلد باید یک Job عملیاتی داشته باشد: Routing، Eligibility، Quote یا تماس. حذف همه فیلدهای Qualification ممکن است Submit را زیاد و هزینه Sales را بیشتر کند. از سوی دیگر، گرفتن کدملی، تاریخ تولد یا جزئیات حساس برای Download ساده نامتناسب است.
Field budget
| فیلد | Job | آیا اکنون لازم است؟ | ریسک |
|---|---|---|---|
| نام | خطاب و CRM | اغلب، نه همیشه | ساختار دوبخشی اجباری برای نام فارسی |
| موبایل/ایمیل | کانال پاسخ | یکی یا هر دو بر اساس SLA | فرمت، Consent و خطای ورود |
| شرکت/نقش | B2B qualification | اگر Routing/Eligibility میسازد | فیلد آزاد بیکیفیت |
| بودجه/اندازه | Fit و Priority | Range یا مرحله بعد | حساسیت و Drop |
| توضیح | Context خاص | اختیاری و با Prompt | ورود داده محرمانه |
| رضایت | هدف مشخص پردازش/بازاریابی | بر اساس مبنای قانونی | Checkbox از پیش انتخابشده |
رفتار فرم
- Label پایدار داشته باشید؛ Placeholder جای Label نیست.
- Keyboard مناسب موبایل، Autofill و فرمت اعداد فارسی/لاتین را تست کنید.
- خطا را کنار فیلد، با متن قابل فهم و Focus مناسب نشان دهید.
- داده کاربر پس از خطای قابل بازیابی بیدلیل پاک نشود.
- دکمه هنگام ارسال State مشخص، Idempotency و جلوگیری از Duplicate داشته باشد.
- موفقیت را از پاسخ Server/Backend تأیید کنید، نه صرفاً Click.
- صفحه/پیام تشکر، زمان پاسخ، کانال و راه اصلاح اطلاعات را بگوید.
راهنمای Input Assistance در WCAG ۲.۲ هدف را کمک به پیشگیری و اصلاح خطا میداند. فرمهای مالی، حقوقی و داده حساس به Error prevention قویتری نیاز دارند.
دسترسپذیری، موبایل و RTL بخشی از Conversion هستند
کاربر صفحه فرود ممکن است با Keyboard، Screen reader، Zoom، Voice input، اتصال ضعیف یا یک دست کار کند. دسترسپذیری را به Checklist انتهایی نسپارید؛ Definition of Done از Design و Copy تا Development و QA است. راهنمای طراحی فراگیر وب و WCAG ۲.۲ مسیر کاملتری برای تست مشارکتی ارائه میکند.
- یک H1 واضح، Landmark و ترتیب Heading منطقی؛
- Contrast، Focus قابل دیدن و Target لمسی کافی؛
- Tab order مطابق ترتیب بصری و Modal بدون Focus trap؛
- Alt متناسب با Job و Caption برای مدرک/منبع؛
- ویدئو با Caption/Transcript و بدون Autoplay آزاردهنده؛
- Zoom ۲۰۰–۴۰۰٪ بدون گم شدن CTA یا خطا؛
- ترکیب متن فارسی، عدد، URL و کد با Direction درست؛
- تست دستگاه ارزان، In-app browser و Keyboard واقعی.
Sticky CTA نباید متن، خطای فرم یا Focus را بپوشاند. Countdown باید برای Screen reader قابل کنترل باشد و اضطراب مصنوعی نسازد. «Call now» در موبایل Secondary action مفیدی است، اما شماره، ساعت پاسخ و هزینه احتمالی تماس روشن باشد.
سرعت و پایداری مقصد؛ Click خریداریشده را هدر ندهید
سرعت یک عدد واحد و تضمین Conversion نیست. Journey را از DNS/Redirect تا LCP، تعامل، Submit و Confirmation اندازه بگیرید. راهنمای Web Vitals، LCP، INP و CLS را Metricهای Field میداند و توصیه میکند توزیع تجربه واقعی دیده شود. برای ساخت Business case و Performance budget به راهنمای سرعت سایت و سنجش اثر مراجعه کنید.
Performance budget لندینگ
- Critical bytes و LCP asset برای موبایل/اتصال هدف؛
- سقف JavaScript و Third-party بر اساس Job، نه عادت؛
- تعداد Redirect و حفظ UTM/GCLID/شناسه کمپین؛
- INP فرم، Date picker، Chat و Consent manager؛
- CLS ناشی از Font، Hero، Banner و Validation؛
- Availability، Error rate و Submit success Backend؛
- Fallback در خرابی CRM، Captcha، Map یا Video embed.
Pixel و Heatmap هم هزینه Performance و Privacy دارند. هر Script باید Owner، Purpose، Consent condition، Data destination، Budget و تاریخ بازبینی داشته باشد. ابزار بدون استفاده را حذف کنید؛ هم سبکتر است و هم سطح ریسک داده را کم میکند.
Tracking plan؛ از Impression تا فروش واقعی
اندازهگیری را قبل از دریافت ترافیک طراحی و در Preview/Production تست کنید. مستند رسمی Lead generation در GA4، `form_start` و `form_submit` را برای تعامل فرم توضیح میدهد. Enhanced measurement میتواند شروع خوبی باشد، اما پیادهسازی سایت، SPA، فرم Ajax و ابزار شخص ثالث را QA کنید؛ Event دیدهشده در Browser هنوز Lead پذیرفتهشده در CRM نیست.
| مرحله | Event نمونه | پارامتر غیرشخصی | Source of truth | QA |
|---|---|---|---|---|
| ورود | landing_view | landing_id، campaign_id، variant_id | Server/Analytics | Redirect و Consent states |
| در معرض CTA/Form | form_view | form_id، placement | Client | Intersection rule |
| شروع | form_start | form_id | Client | یک بار در Session/Form |
| خطا | form_error | field_code، error_code | Client/Server | بدون مقدار PII |
| ارسال | form_submit | form_id، request_id | Server preferred | Success response، Dedup |
| پذیرش Lead | qualified_lead | lead_id hash، stage | CRM | Rule و Timestamp |
| نتیجه | purchase/activation | order_id، value، currency | Backend/Finance | Refund/Cancel reconciliation |
PII را به Analytics نفرستید
نام، موبایل، ایمیل، متن آزاد یا داده حساس را در URL، UTM یا Event parameter قرار ندهید. شناسه داخلی را در محیط کنترلشده و طبق Policy به CRM متصل کنید. Query string ممکن است در Log، History، Screenshot و Referrer باقی بماند. Consent state، Retention، Access و Delete workflow را مستند کنید.
سه منبع را Reconcile کنید
Platform click، Analytics session و Backend order قواعد شمارش متفاوت دارند. جدول روزانه Click→Landing→Submit→Accepted→Outcome با شناسههای کنترلشده و Window مشخص بسازید. اختلاف را پنهان نکنید؛ Redirect loss، Ad blocker، Consent، Duplicate، Offline sale و Cross-device را در Limitation بنویسید. معماری کاملتر در راهنمای GA4، CRM و Warehouse آمده است.
A/B تست لندینگ پیج؛ سؤال را قبل از Variant بنویسید
A/B تست جای Research یا رفع Bug نیست. اگر Submit کار نمیکند، Message با Ad ناسازگار است یا صفحه روی موبایل دیر باز میشود، ابتدا نقص آشکار را اصلاح کنید. آزمون وقتی ارزش دارد که عدمقطعیت مهم، ترافیک کافی و امکان اجرای تغییر برنده وجود داشته باشد.
Experiment brief
Observation → Hypothesis → Change → Primary metric → Guardrails → Segment → MDE → Stop rule → Decision
مثال فرضی: «مصاحبه فروش نشان میدهد مدیر مالی قبل از Demo درباره زمان استقرار نگران است؛ نمایش Timeline و پیشنیاز نزدیک CTA، نرخ Lead پذیرفتهشده را حداقل ۱۵٪ نسبی بهتر میکند، بدون افزایش No-show یا افت سرعت.» این فرض از «تیتر B بهتر است» قابل یادگیریتر است.
یک تغییر یا یک Concept؟
برای تشخیص علت جزئی، یک عامل اصلی را تغییر دهید. اما در Redesign میتوان یک Concept منسجم—Offer، Copy و Layout هماهنگ—را با Control مقایسه کرد؛ نتیجه درباره کل Concept است، نه رنگ یا جمله خاص. قانون «همیشه فقط یک عنصر» نیز نسخه عمومی و غیرضروری است.
| ریسک اعتبار آزمون | نشانه | کنترل |
|---|---|---|
| Sample ratio mismatch | توزیع ۵۰/۵۰ بهطور غیرعادی شکسته | Assignment/Eligibility/Logging audit |
| Peeking و توقف زود | با اولین سبز شدن پایان میدهید | روش و Stop rule از پیش نوشتهشده |
| Seasonality/Campaign mix | Variantها Source/روز متفاوت دارند | Randomization و Full-cycle coverage |
| Cross-device/Repeat | کاربر هر دو Variant را میبیند | Assignment ID و تحلیل حساسیت |
| Bot/Spam | Submit زیاد، Lead معتبر ثابت | Backend validation و Qualified metric |
| Novelty/Instrumentation | اثر کوتاه یا Event متفاوت | QA و بازه کافی |
| Multiple comparisons | ده Metric و یک Winner تصادفی | Primary metric و تصحیح/تفسیر محتاط |
اگر ترافیک کم است
آزمون کمقدرت را تا یافتن «معناداری» ادامه ندهید. مصاحبه، تست کاربردپذیری، Log خطا، Funnel، Rollout مرحلهای و تحلیل Cohort میتواند شواهد بهتری بدهد. Pre/post را با Seasonality، Campaign mix و تغییرات همزمان گزارش کنید و از ادعای علیت قطعی بپرهیزید. نتیجه «شواهد کافی نداریم» تصمیم معتبر است.
سئو و مدیریت نسخههای لندینگ
صفحه فرود ذاتاً مناسب یا نامناسب سئو نیست؛ Intent، ارزش مستقل و Governance آن تعیینکننده است. صفحهای که پاسخ پایدار و متمایز دارد میتواند Index شود. نسخه کوتاه تبلیغاتی، Thank-you، Preview، پارامتر Tracking یا Variant نزدیکبهتکراری معمولاً نباید URL مستقل قابل ایندکس بیهدف بسازد.
Index، Canonical و noindex را قاطی نکنید
- برای پارامتر و نسخه بسیار مشابه، URL اصلی تمیز و Canonical مورد ترجیح را مشخص کنید.
- برای صفحهای که نباید در Search باشد، `noindex` آگاهانه بگذارید؛ راهنمای رسمی noindex گوگل هشدار میدهد صفحه نباید در robots.txt مسدود باشد، چون Crawler باید Rule را ببیند.
- صفحههای متفاوت از نظر Offer/Audience را صرفاً برای حذف از گزارش به صفحه دیگری Canonical نکنید.
- Thank-you، Token URL و اطلاعات شخصی را با Auth/Access control محافظت کنید؛ noindex کنترل امنیتی نیست.
A/B تست و Google Search
راهنمای رسمی A/B testing برای Google Search توصیه میکند به Googlebot و کاربر محتوای متفاوتِ فریبنده نشان ندهید، Variantهای URLدار را به نسخه اصلی Canonical کنید، Redirect آزمایش را ۳۰۲ بگذارید و پس از پایان، اجزای تست را جمع کنید. این راهنما جای طراحی آماری آزمون نیست؛ اثر Search را مدیریت میکند.
صفحه Organic با لندینگ Paid یکی است؟
گاهی یک صفحه میتواند هر دو Job را انجام دهد، اگر Query intent و Promise تبلیغ همراستا باشند. اما حذف Navigation، متن کوتاه یا Offer موقت ممکن است نیاز Search user را ناقص کند. داده Paid و Organic را Segment کنید؛ Variant کمپین نباید به Cannibalization یا محتوای تاریخگذشته تبدیل شود.
ورودیهای مختلف، قراردادهای مختلف
Paid Search
Query/Ad group، Ad promise، Final URL، Tracking، Eligibility و Destination policy را کنار هم QA کنید. سیاست رسمی Destination requirements گوگل ادز مقصد را functional، useful و easy to navigate میخواهد و مواردی مانند مقصد در حال ساخت، ناسازگار با Browser یا غیرفعال کردن Back را مشکل میداند. برای محدودیتها و اجرای قانونی مرتبط با ایران از راهنمای Google Ads، Eligibility و سنجش سود استفاده کنید؛ هیچ دورزدنی توصیه نمیشود.
Social و Creator
In-app browser، Caption/Creative، Link sticker، UTM، Mobile keyboard و Page speed را روی شبکه هدف تست کنید. کاربر از Feed با Context کمتر میآید؛ Visual/message continuity مهم است. معماری Click→Landing و Dark Social در راهنمای ترافیک شبکههای اجتماعی و UTM عمیقتر است.
Email، پیامک و CRM
Audience شناختهشده است، اما Token/PII را در URL قرار ندهید. Preference و Consent، Deep link، Expiry Offer و بازگشت به Journey را حفظ کنید. صفحه لغو یا Preference center را به Dark pattern تبدیل نکنید.
QR، Offline و Partner
URL کوتاهِ متعلق به خودتان، شناسه Campaign غیرشخصی و Fallback خوانا داشته باشید. QR را با دوربینهای مختلف، نور و چاپ واقعی تست کنید. Partner باید Claim، برند، UTM taxonomy و تاریخ پایان یکسان داشته باشد.
قانون، حریم خصوصی و عملیات پس از تبدیل در ایران
این بخش مشاوره حقوقی نیست و باید با حقوقدان و مقررات حوزه خود بررسی شود. متن قانون تجارت الکترونیکی ایران در WIPO Lex در مواد ۳۳ تا ۳۵ بر اطلاعات مؤثر پیش از معامله، در مواد ۵۰ تا ۵۴ بر پرهیز از فریب، توصیف روشن و هویت تبلیغکننده، و در مواد ۵۸ و ۵۹ بر داده خصوصی/حساس و شرایط پردازش تأکید دارد. دامنه دقیق تکلیف را حقوقدان تعیین کند.
Privacy notice نزدیک فرم
بگویید چه دادهای، برای چه هدفی، توسط چه هویتی، تا چه مدت و با چه کانال پیگیری پردازش میشود؛ Link به Policy کامل بدهید. رضایت Marketing را با اجرای درخواست اصلی قاطی نکنید. داده حساس را فقط با ضرورت، مبنای قانونی و کنترل متناسب بگیرید.
Conversion بدون Handoff کامل نیست
Lead اگر سه روز در CRM بماند، بهبود Hero کمکی نمیکند. Routing، Dedup، Owner، SLA اولین پاسخ، Retry، وضعیت نامعتبر و Feedback reason از Sales را طراحی کنید. برای E-commerce، Landing→Product→Cart→Payment را یک Journey ببینید؛ تشخیص خطای Checkout و Recovery در راهنمای سبد خرید رهاشده پوشش داده شده است.
| شکست عملیات | نشانه | Owner | کنترل |
|---|---|---|---|
| Lead وارد CRM نمیشود | GA4 Submit دارد، CRM ندارد | Engineering/RevOps | Server ack، Queue، Alert و Replay |
| Duplicate | چند رکورد/تماس | CRM | Request ID و Dedup window |
| پاسخ دیر | Lead سرد یا No-show | Sales | SLA و Escalation |
| Qualification مبهم | اختلاف Marketing/Sales | Revenue owner | Rule و Reason code مشترک |
| Offer تمام شده | Ad فعال، صفحه منقضی | Campaign owner | Expiry، Monitor و Fallback |
| ابزار خارجی قطع | Captcha/Chat/Form fail | Product/SRE | Eligibility register و مسیر جایگزین مجاز |
دو مثال فرضی ایرانی
مثال B2B: دموی نرمافزار انبار
Source یک Search ad برای «نرمافزار انبار چند شعبه» است. Hero همان Context را ادامه میدهد؛ Offer یک Demo همراه با بررسی فایل نمونه است. Fit شامل حداقل دو شعبه و API حسابداری موجود، Not-fit شامل نیاز به سختافزار اختصاصیِ پشتیبانینشده است. Evidence یک ویدیوی ۹۰ثانیهای واقعی و Sample report است. فرم نام، کانال تماس، تعداد شعبه و نرمافزار فعلی میگیرد. Primary metric «Demo برگزارشده واجد شرایط» و Guardrail زمان اولین پاسخ و No-show است؛ نه Form submit.
مثال فروشگاهی: کمپین کولهپشتی
Source یک Creative اجتماعی برای «ارسال رایگان سفارش بالای مبلغ مشخص تا تاریخ واقعی» است. لندینگ مجموعهای محدود با قیمت تومان، شرط ارسال، موجودی Variant، ابعاد، تصویر کاربرد، سیاست بازگشت و فیلتر مناسب لپتاپ را نشان میدهد. CTA به Product/Cart میرود، نه فرم Lead. Outcome سفارش موفق پس از لغو/مرجوعی و Guardrail حاشیه سود، خطای موجودی و Return reason است. اگر Offer تمام شد، صفحه و Creative همزمان Update یا متوقف میشوند.
سیستم تولید و Governance لندینگ
ساخت هر صفحه از صفر، Drift و هزینه QA ایجاد میکند. Design system لندینگ باید انعطاف Context را حفظ کند، نه اینکه همه Offerها را در یک Template فشرده کند. Componentها Contract محتوایی، دسترسپذیری، Performance و Event دارند.
Landing registry
برای هر صفحه ثبت کنید: Landing ID، URL، Owner، Source/Campaign، Audience، Offer، Primary metric، Status، Index policy، Canonical، Variant، Start/End، Privacy/Legal review، CRM route و آخرین QA. Job منقضی باید Archive، Redirect، Update یا noindex شود—با تصمیم ثبتشده، نه رها.
سه Gate انتشار
- Truth/Legal gate: Offer، Claim، قیمت، هویت، Consent، Rights و Expiry؛
- Experience gate: Responsive، RTL، Keyboard، Screen reader، Form، Error، سرعت و Browser؛
- Data/Operations gate: UTM، Event، Dedup، CRM، SLA، Dashboard، Alert و Rollback.
| نقش | مالکیت اصلی | شاهد تأیید |
|---|---|---|
| Campaign/Product owner | Outcome، Audience، Offer و Deadline | Brief و Decision log |
| Copy/Content | Message، Claim، FAQ و Freshness | Source/Claim ledger |
| Design | Hierarchy، States و Accessibility | Prototype و Spec |
| Engineering | Delivery، Form، Integration و Release | Test/Monitor/Rollback |
| Data | Event contract، QA و Experiment | Debug و Reconciliation |
| Legal/Privacy | Claim، Notice، Consent و Retention | Review تاریخدار |
| Sales/Operations | Qualification، Routing و SLA | Reason code و CRM report |
برنامه ۳۰ روزه ساخت اولین لندینگ قابلسنجش
روز ۱ تا ۵: تصمیم و Baseline
- Source، Audience، Stage، Outcome و Unit economics را تعریف کنید.
- مصاحبه فروش/پشتیبانی و Query/Creative را مرور کنید.
- Message map، Offer spec، Claim ledger و Riskها را بسازید.
روز ۶ تا ۱۲: محتوا و Prototype
- سه Story order ممکن بسازید و با پنج تا هشت کاربر هدف تست کیفی کنید.
- فرم، Qualification، Privacy notice، Success/Error و Handoff را طراحی کنید.
- Index policy، URL، UTM و Asset rights را تعیین کنید.
روز ۱۳ تا ۲۰: Build و Instrument
- Componentهای Responsive و دسترسپذیر را پیاده کنید.
- Event contract، Server confirmation، CRM route و Dashboard را وصل کنید.
- Performance budget، Security، Consent و Third-partyها را QA کنید.
روز ۲۱ تا ۳۰: Launch و Learning
- Canary/Soft launch، Browser/Device/Network و لینک منبع را تست کنید.
- Click→Landing→Submit→CRM reconciliation و Alert را بررسی کنید.
- Bug واضح را رفع؛ سپس Experiment backlog را بر ارزش و توان آزمون اولویت دهید.
- جلسه Review با Sales/Data برگزار و تصمیم بعدی را ثبت کنید.
چکلیست انتشار و بهینهسازی لندینگ پیج
- □ Source، Audience، Stage و یک Primary outcome تعریف شدهاند.
- □ Message، Offer، قیمت/شرط و Visual با منبع سازگارند.
- □ H1 میگوید صفحه برای چه کسی و چه نتیجهای است.
- □ هر Claim مهم Source، Owner، Boundary و تاریخ دارد.
- □ Fit، Not-fit، محدودیت و چیزی که Included نیست روشناند.
- □ CTA قدم بعد و اتفاق پس از آن را دقیق میگوید.
- □ هر فیلد فرم Job دارد و PII در URL/Event نمیرود.
- □ Error، Loading، Success، Duplicate و Retry تست شدهاند.
- □ Privacy notice، Consent، Retention و حقوق Asset مرور شدهاند.
- □ Keyboard، Focus، Screen reader، Zoom، Contrast و RTL QA شدهاند.
- □ Mobile، In-app browser، اتصال ضعیف و Browserهای هدف تست شدهاند.
- □ LCP/INP/CLS، JS/Third-party و Submit availability بودجه دارند.
- □ UTM/شناسهها غیرشخصیاند و Redirect آنها را حفظ میکند.
- □ Landing view، Form، Error، CRM و Outcome Reconcile میشوند.
- □ Primary metric، Qualification، Guardrail و Unit economics مستندند.
- □ Index/noindex/Canonical و نسخههای آزمایش تصمیم ثبتشده دارند.
- □ CRM routing، Owner، SLA، Feedback reason و Alert کار میکنند.
- □ Campaign/Offer expiry و Archive/Redirect plan تعیین شده است.
- □ آزمون بعدی Hypothesis، MDE، Stop rule و Decision دارد.
پرسشهای متداول لندینگ پیج
لندینگ پیج چه تفاوتی با صفحه اصلی دارد؟
صفحه اصلی معمولاً چند مخاطب و مسیر را معرفی میکند؛ لندینگ برای Context، Audience، Offer و اقدام مشخص ساخته میشود. با این حال «لندینگ» همیشه صفحه جدا یا بدون منو نیست؛ اگر صفحه خدمت دقیقاً Promise و نیاز کمپین را پوشش دهد، میتواند مقصد باشد.
آیا لندینگ پیج باید فقط یک CTA و بدون منو باشد؟
یک Primary action مفید است، اما میتواند چند بار تکرار شود و لینکهای اعتماد، حریم خصوصی یا جزئیات ضروری را حذف نمیکند. منو را بر اساس Stage و ریسک حواسپرتی محدود کنید؛ نه با قانون ثابت. Secondary path گاهی به کاربرِ هنوز آماده کمک میکند.
فرم لندینگ چند فیلد داشته باشد؟
عدد ثابت وجود ندارد. حداقل داده لازم برای انجام قدم بعد، Routing و Qualification را بگیرید و بقیه را به مرحله مناسب منتقل کنید. هر فیلد باید Job، مبنای پردازش و Owner داشته باشد؛ Submit کمتر اما Lead معتبرتر ممکن است نتیجه اقتصادی بهتری باشد.
آیا هر لندینگ پیج باید در گوگل ایندکس شود؟
نه. صفحه با ارزش مستقل و Intent پایدار میتواند Index شود؛ Variant آزمایش، Thank-you، Preview و کمپین تکراری اغلب نیازمند Canonical یا noindex آگاهانهاند. Canonical، noindex و Access control وظایف متفاوت دارند و باید برای هر URL ثبت شوند.
A/B تست را از چه زمانی شروع کنیم؟
پس از صحت Offer، رفع Bug، نصب Measurement، اتصال Backend و داشتن عدمقطعیت مهم و ترافیک کافی. آزمون باید Hypothesis، Primary metric، Guardrail، MDE و Stop rule داشته باشد. در ترافیک کم، تحقیق کیفی و تحلیل خطا میتواند از آزمون کمقدرت مفیدتر باشد.
جمعبندی: لندینگ پیج یک پوستر دیجیتال نیست؛ قرارداد اجرایی میان منبع ورودی، وعده، Evidence، اقدام و عملیات پس از آن است. ابتدا Outcome و اقتصاد را تعریف کنید، سپس Offer و پیام را بسازید، فرم و تجربه را دسترسپذیر و سریع تحویل دهید، داده را تا CRM/فروش Reconcile کنید و فقط با فرضیه قابل تصمیم آزمایش کنید.
