ساخت سایت تبلیغات تولیدی

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

اختلاف های تبلیغات سنتی و مدرن در ساخت سایت تبلیغات تولیدی

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

با این حال، در دنیا چگونه این موتور تبلیغاتی در پشت صحنه کار می کند؟ اگر بخواهیم سیستم تبلیغاتی خود را بسازیم تا تبلیغات را در پلتفرم خود نیز ارائه دهیم، چه؟ (اما، صادقانه بگویم، برای یک تجارت کوچک یا توسعه دهنده، من پیشنهاد می کنم از راه حل های موجود مانند Google DFP استفاده کنید. امروز، من قصد دارم طراحی سیستم فنی ساخت سایت تبلیغات تولیدی را به شما نشان دهم، تا شاید پس از خواندن الهام بگیرید.)

بررسی اجمالی ساخت سایت تبلیغات تولیدی

سیستم تبلیغات هیچ تفاوتی با تبادل زنده ندارد. اطلاعات را بین دو طرف مبادله می کند:

• تبلیغ کنندگان
• کاربران نهایی

در دنیای ایده آل، ما فقط به این موارد نیاز داریم:

1. یک رابط وب که در آن تبلیغ کنندگان یا فروشندگان داخلی بتوانند سفارش را مدیریت کنند.
2. برنامه مشتری شما که در آن تبلیغات نمایش داده می شود.
3. یک سیستم پشتیبان که این سفارشات را حفظ می کند و فیلتر می کند که کدام آگهی ارائه شود. متأسفانه، این طرح به دلیل محدودیت‌های کم، برای یک تجارت تبلیغاتی جدی مقیاس مناسبی ندارد.

محدودیت های ساخت سایت تبلیغات تولیدی

اولین محدودیت  فرکانس است. تبلیغ‌کنندگان، مخاطبان هدف خود را تنظیم می‌کنند تا به بیشترین تعداد مخاطب دسترسی پیدا کنند. با این حال، به‌عنوان یک پلتفرم، نمی‌خواهید با نمایش تبلیغات زیاد به تجربیات کاربران آسیب بزنید. حتی اگر همیشه اطلاعات مفیدی را به کاربران پیشنهاد می کنید، باز هم باعث حواس پرتی از سرویس اصلی شما می شود.

محدودیت دوم سرعت است. برخلاف پست ها، تصاویر و ویدئوها، تبلیغات بسیار پویاتر هستند. یک کمپین تبلیغاتی ممکن است در هر زمانی به بودجه خود برسد و هر ثانیه لغو شود. با این حال، برای اینکه تبلیغات به بخشی ثابت از پلتفرم خود تبدیل شود، باید آن را با سرعت انجام دهیم. زمانی که زمان پاسخگویی تبلیغات بیشتر از سایر خدمات باشد، حتی باید فرصت تبلیغات را به طور کامل کنار بگذاریم.

محدودیت سوم  کیفیت است. اگرچه رعایت دو محدودیت اول باعث می شود که موتور تبلیغات به راحتی کار کند، شما باید تبلیغ مناسب را در جایی که بیشتر به آن نیاز دارید ارائه دهید تا سود خود را به حداکثر برسانید. اگر بتوانید برای وب سایت خود کلیک کنید یا برنامه خود را نصب کنید، تبلیغ کنندگان معمولاً مایلند ده ها یا صدها برابر پول بپردازند. بنابراین، هرچه تعامل بیشتری از کاربران به دست آورید، درآمد بیشتری کسب می کنید. از این رو ما باید احتمال چنین تعاملاتی را به حداکثر برسانیم.

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

بررسی سیستم ساخت سایت تبلیغات تولیدی

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

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

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

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

بررسی اجزای ساخت سایت تبلیغات تولیدی

در ادامه عمیقا به هر مولفه در این سیستم تبلیغاتی می پردازیم تا در مورد جزِئیات فنی اطلاعات بیشتری کسب کنید.

رابط وب

همانطور که در بالا ذکر کردم، یک سیستم تبلیغات اساسا یک تبادل اطلاعات است. بنابراین اولین چیز این است که راهی برای تغذیه همه اطلاعات به این تبادل داشته باشید.

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

مدیریت تبلیغات

قبل از اینکه به مشکلات فنی خاص بپردازم، ابتدا با سلسله مراتب تبلیغات دیجیتال معمولی آشنا می شویم. معمولاً یک تبلیغ‌کننده  کمپینی ایجاد می‌کند که نشان دهنده یک ابتکار بازاریابی است.

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

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

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

چالش های رابط وب

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

به عنوان مثال، برای ایجاد امکان خرید یک تبلیغ ویدیویی ساده، نرم افزار باید قبل از اینکه کاربر داده ها را متعهد کند، تمام سلسله مراتب، ابرداده ها و اطلاعات هدف را در یک مکان موقت حفظ کند. هر موجودیت همچنین دارای هزاران فیلد مختلف است که ممکن است با فیلدهای دیگر در هم تنیده شوند.

هدف یک  کمپین  می تواند بر نوع تبلیغی که می توانید بخرید تأثیر بگذارد. مکان یابی یک  مجموعه تبلیغاتی  می تواند حداقل بودجه روزانه را تعیین کند. نوع  تبلیغ همچنین می‌تواند گزینه‌های «تماس برای اقدام» را محدود کند.

چالش بزرگ دیگر تنوع زیادی از اجزای رابط کاربری است که توسط جریان کسب و کار مورد نیاز است. به عنوان مثال، اجازه دهید هنگام ایجاد یک کمپین به بخش هدف گذاری نگاهی بیندازیم.

مکان یابی به یک جزء نقشه نیاز دارد. گروه مخاطب به یک جزء انتخاب درخت نیاز دارد. تنظیم مدت زمان یک انتخابگر محدوده تاریخ است. علاوه بر این، همه این مؤلفه ها می توانند در هر مکانی از برنامه شما ظاهر شوند، بنابراین بهتر است بیشتر آنها را مجدداً استفاده کنید یا حداقل آنها را انتزاعی کنید.

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

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

استفاده از رابط کاربری فیسبوک

خوشبختانه، فیسبوک چند سال پیش چارچوب رابط کاربری  React.js خود را منبع باز کرده است. با پذیرش فلسفه Flux و کپسوله‌سازی خوب اجزا، معتقدم که این راحت‌ترین راه برای ساختن یک برنامه وب تبلیغ‌کننده است.

الگوی Flux به سردرد حالت های درهم تنیده می پردازد و JSX نوشتن اجزای رابط کاربری قابل استفاده مجدد را بسیار آسان می کند. علاوه بر این، شما همچنین می توانید  Redux را به پشته فناوری خود اضافه کنید تا انتقال حالت را قابل پیش بینی تر و قابل نگهداری تر کنید.

تقسیم بندی رابط کاربری وب

با پشته فناوری مناسب، اکنون می‌توانیم این رابط کاربری وب را به بخش‌های اصلی زیر تقسیم کنیم:

جداول صفحه اصلی

جایی که همه نهادها مانند  Campaign، Ad نشان داده می شوند. از اینجا نیز می توان ویرایش های بیشتری را انجام داد.

جریان ایجاد

یک فرم جادوگر که به تبلیغ کننده (یا عملیات تبلیغات داخلی) کمک می کند تا یک سفارش را مرحله به مرحله انجام دهد.

آمار و گزارش

جایی که تبلیغ‌کنندگان می‌توانند عملکرد تبلیغات را مانند تعداد نمایش‌ها ردیابی کنند، و همچنین داده‌ها را برای مرجع صادر کنند.

کتابخانه دارایی

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

صورتحساب و پرداخت

برای مدیریت منبع پرداخت و مشاهده اطلاعات صورتحساب. این بخش معمولاً با API های Braintree ادغام می شود تا از منابع مالی بیشتر پشتیبانی کند.

حساب

برای مدیریت سلسله مراتب نقش و کنترل دسترسی چند کاربر. معمولاً یک سازمان بزرگ چندین حساب تبلیغاتی دارد. همچنین نقش های مختلف دسترسی متفاوتی خواهند داشت.

مدیر مخاطب

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

بخش Onboarding

این ممکن است حیاتی ترین بخش ساخت سایت تبلیغات تولیدی در مراحل اولیه باشد. یک تجربه ورود خوب می تواند ثبت نام را به میزان قابل توجهی افزایش دهد.

با یک رابط وب خوب، اصطکاک خرید یک آگهی در سیستم ما می تواند از این به بعد به حداقل برسد. با این حال، به خاطر داشته باشید که رابط کاربری گرافیکی تنها ورودی سیستم ما نیست.

شیوه استفاده از API ها

اول از همه، Ads APIs چیست؟ چرا ما به آن احتیاج داریم؟ همانطور که از پاراگراف آخر می بینید، رابط وب ما باید فرم بسیار پیچیده ای را مدیریت کند و به مشتریان ما کمک کند تا سفارشات خود را مدیریت کنند. برای تداوم همه این تغییرات و همچنین ارائه داده برای رابط کاربری، به یک لایه سرویس برای انجام CRUD نیاز داریم. با این حال، اگر این تنها عملکرد باشد، آن را API نمی نامیم. این فقط می تواند مانند هر باطن دیگری باشد.

در واقع، تبلیغ کنندگان معمولاً همه تخم مرغ ها را در یک سطل قرار نمی دهند. آنها علاوه بر استفاده از این رابط وب که برای آنها ساخته ایم، با برخی آژانس های تبلیغاتی نیز مشورت می کنند و بخشی از بودجه خود را در آنجا خرج می کنند.

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

برای رویارویی با آژانس های شخص ثالث، اغلب بهترین راه، ساختن  API های RESTful  است، زیرا این تقریباً راه استاندارد برای برقراری ارتباط دو طرف ناآشنا است. راه‌حل‌های جذاب‌تری مانند gRPC و GraphQL نیز وجود دارد، اما RESTful می‌تواند بیشترین سازگاری را در اینجا تضمین کند. علاوه بر این، نوشتن اسناد عمومی برای API های RESTful نیز آسان تر است زیرا چیزها بر اساس منابع و روش ها گروه بندی می شوند. به مراجع API توییتر نگاهی بیندازید.

API  های توییتر

اکنون که ما یک ایده کلی از نحوه ساختار API های خود داریم. می خواهیم به طور خلاصه در مورد چهار ستون در پیاده سازی این API ها صحبت کنم.

مدیریت کمپین تبلیغات توییتر در ساخت سایت تبلیغات تولیدی

به‌طور خلاصه، مدیریت کمپین، هسته اصلی همه نهادهای تبلیغاتی است که در بخش آخر فهرست کردیم. با این حال، از منظر تجاری، این امر پیچیده تر از حفظ برخی ارزش ها است.

اول، ما باید با هزاران اعتبار برای انواع قوانین تجاری مقابله کنیم. از این رو، یک الگوی طراحی مناسب مانند نما و انتزاع منسجم با استفاده از رابط ها و وراثت مهم هستند.

دوم، برای اطمینان از قابل مدیریت بودن گردش کار، احتمالاً در اینجا از یک ماشین حالت برای حفظ وضعیت متفاوت کمپین ها، مجموعه تبلیغات یا تبلیغات استفاده می شود.

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

این نوع کارهای ناهمزمان معمولاً توسط برخی از سیستم‌های PubSub یا TaskQueue کنترل می‌شوند و با دستگاه حالتی که قبلاً ذکر کردم یکپارچه می‌شوند. چهارم، پایگاه داده شما باید تراکنش ها را به روشی مقیاس پذیر پشتیبانی کند، زیرا بیشتر عملیات ها در مدیریت کمپین ممکن است بر چندین جدول تأثیر بگذارد.

کنترل دسترسی

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

اما اغلب، یک رمز برای API های بدون حالت RESTful ترجیح داده می شود. ما می توانیم از OAuth 2.0 شخص ثالث استفاده کنیم یا خودمان بسازیم. یک مبادله توکن JWT ساده ممکن است به اندازه کافی امن نباشد زیرا در اینجا در مورد تجارت با پول واقعی صحبت می کنیم. مجوز نیز بخش بزرگی است.

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

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

صورتحساب و پرداخت

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

با این حال، برای پذیرش منبع پرداخت عمومی مانند کارت اعتباری، به احتمال زیاد باید از خدمات شخص ثالث کمک بخواهید. Braintree و Stripe هر دو راه حل پیشرو پرداخت برای شرکت هستند. علاوه بر این، یکی دیگر از نگرانی های منبع پرداخت خارجی، خطر سوء استفاده و هرزنامه است. محدودیت نرخ مناسب، هشدار ناهنجاری، و ممیزی منظم باید برای جلوگیری از چنین خطری اعمال شود.

معیارها و گزارش‌گیری

آخرین اما نه کم‌اهمیت، Ads API گزارش‌دهی را هم برای آژانس‌های تبلیغاتی و هم برای رابط وب ما انجام می‌دهد. چالش گزارش‌دهی بر اساس انبار داده و نحوه جمع‌آوری معیارها می‌تواند بسیار متفاوت باشد. بنابراین هنگام طراحی خط لوله مجموعه معیارها، به خصوص برای نتایج انبوه، مراقب باشید. برای مثال، زمانی که جزئیات در جستجوی آمار هفتگی باشد، ممکن است برخی از داده‌ها در دسترس نباشند.

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

هنوز ماژول های بسیار بیشتری در یک سیستم  APIهای تبلیغاتی تولید واقعی وجود دارد، مانند کنترل بودجه، خط لوله بررسی محتوا و غیره. ما همچنین می‌توانیم مدل‌های یادگیری ماشینی را برای انجام برچسب‌گذاری خودکار برای تسریع روند بررسی، ترکیب کنیم. با این حال، شما باید درک خوبی از اینکه اکنون از کجا شروع کنید، داشته باشید.