اگر من بنیان‌گذار Kaito بودم، InfoFi 2.0 چگونه زنده می‌ماند؟

عنوان اصلی: What If: I Were the Founder of Kaito?
نویسنده اصلی: RYAN YOON, TIGER RESEARCH
ترجمه: Peggy, BlockBeats

یادداشت سردبیر: یک تغییر ناگهانی در سیاست API باعث شد InfoFi ظرف سه روز «به‌طور دسته‌جمعی منجمد» شود. این فروپاشی نه تنها وابستگی عمیق Web3 به پلتفرم‌های متمرکز را آشکار کرد، بلکه روی دیگر مکانیسم‌های تشویقی را نیز فاش کرد: هرچه پاداش بیشتر باشد، فعالیت‌های رباتیک سریع‌تر انجام می‌شود و کنترل کیفیت دشوارتر می‌گردد.

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

در ادامه متن اصلی آمده است:

نکات کلیدی

تغییر سیاست X باعث فروپاشی اکوسیستم InfoFi در عرض سه روز شد و محدودیت‌های ساختاری وابستگی بیش از حد به پلتفرم‌های متمرکز را آشکار کرد.

پروژه InfoFi در حال حاضر با پنج انتخاب روبروست: تعطیلی؛ گذار به یک پلتفرم وظیفه‌محور مبتنی بر مکانیسم پاداش؛ اتخاذ مدل نوشتن محتوای حمایت‌شده از برند به سبک کره‌ای؛ گسترش به عملیات چند پلتفرمی؛ یا تبدیل به مدل مدیریت KOL به سبک MCN.

InfoFi 2.0 احتمالاً به یک مدل کوچک‌تر و قابل کنترل‌تر تبدیل خواهد شد و از «گسترش مقیاس بزرگ بدون مجوز» به «همکاری بین KOLهای منتخب و تیم‌های پروژه» تغییر جهت خواهد داد.

دو چالش اساسی همچنان حل‌نشده باقی مانده‌اند: چگونگی ایجاد یک سیستم پاداش عادلانه و چگونگی ارائه حمایت معقول برای ارزش توکن.

فروپاشی InfoFi در عرض سه روز

منبع: X (@nikitabier)

در ۱۵ ژانویه، نیکیتا بیر، مدیر محصول X، به‌روزرسانی کوتاهی منتشر کرد و به‌وضوح اعلام کرد که این پلتفرم دیگر به برنامه‌هایی که «پاداش را با پست مبادله می‌کنند» اجازه فعالیت نخواهد داد. برای پروژه InfoFi، این تقریباً معادل حکم روز قیامت بود.

طبق بررسی یو هو، بنیان‌گذار Kaito، روند این رویداد تقریباً به شرح زیر بود:

۱۳ ژانویه: Kaito ایمیلی از X دریافت کرد مبنی بر اینکه ممکن است وارد فرآیند حسابرسی شوند. تیم بلافاصله پاسخی برای درخواست شفاف‌سازی بیشتر ارسال کرد.

۱۴ ژانویه: X یک اخطار حقوقی رسمی صادر کرد و Kaito در همان روز پاسخ حقوقی خود را ارسال کرد.

۱۵ ژانویه: پست عمومی نیکیتا بیر منتشر شد. Kaito، مانند همه افراد دیگر، تقریباً همزمان از تصمیم نهایی مطلع شد.

واکنش بازار بی‌رحمانه بود.

$KAITO به‌سرعت سقوط کرد و جامعه نیز شروع به انتقاد از تیم کرد که «ادعا می‌کردند طرح اضطراری دارند اما از قبل در مورد ریسک هشدار نداده‌اند». همان شب، Kaito بیانیه‌ای اضطراری صادر کرد و توضیح داد که در گذشته نیز اخطارهای حقوقی از X دریافت کرده‌اند که همگی در نهایت با امضای توافق‌نامه‌های جدید حل شده‌اند. بنابراین، این بار تیم تصمیم گرفت ابتدا منتظر ارتباط و مذاکره بیشتر بماند.

با این حال، صرف‌نظر از توضیحات، واقعیت به‌اندازه کافی روشن شده بود: یک تصمیم X مستقیماً به کل اکوسیستم InfoFi پایان داد. تنها در سه روز، کل یک حوزه کاملاً فروپاشید زیرا پلتفرم آن را برای تجربه کاربری و کیفیت محتوا مضر تشخیص داد.

اگر امروز بنیان‌گذار یک پروژه InfoFi بودم

آیا این بدان معناست که InfoFi تمام شده است؟ پروژه‌هایی مانند Kaito در واقع برای مراحل بعدی آماده می‌شدند. اما آنچه اکنون واقعاً مورد نیاز است، ادامه مدل قدیمی نیست، بلکه یافتن شکل متفاوتی از InfoFi 2.0 است.

اگر من بنیان‌گذار یک پروژه InfoFi مانند Kaito بودم، چه گزینه‌های واقع‌بینانه‌ای امروز باقی مانده است؟ با بررسی این مسیرهای «عملی»، ممکن است بتوانیم ترسیم کنیم که مرحله بعدی InfoFi چگونه خواهد بود.

تعطیلی

این مستقیم‌ترین و ساده‌ترین گزینه است: کوچک‌سازی و توقف عملیات به‌محض اتمام بودجه. در واقعیت، بسیاری از پروژه‌های کوچک و متوسط احتمالاً وارد «وضعیت زامبی» می‌شوند، دیگر محصول را به‌طور فعال به‌روزرسانی نمی‌کنند، گاهی اوقات در شبکه‌های اجتماعی پست می‌گذارند و سپس به‌آرامی محو می‌شوند.

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

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

پلتفرم وظیفه‌محور مبتنی بر پاداش

هنگامی که امکان استفاده از API X وجود ندارد، جایگزین عملی بازگشت به یک مدل تشویقی «سنتی‌تر» است: KOLها مستقیماً برای شرکت در فعالیت‌ها ثبت‌نام کنند، محتوای آن‌ها برای بررسی دستی ارسال شود، تأیید گردد و سپس به آن‌ها پاداش داده شود.

این مکانیسم اساساً بیشتر شبیه «پلتفرم‌های وظیفه» یا «برنامه‌های باونتی» اولیه است: KOLها فعالانه درخواست می‌دهند؛ تیم پروژه به‌صورت دستی غربالگری کرده و وظایف را اختصاص می‌دهد؛ تولیدکنندگان محتوا را ارسال می‌کنند؛ پلتفرم پس از تأیید، پاداش‌ها را تسویه می‌کند.

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

منبع: Scribble

Scribble یک مورد نمونه است. تیم پروژه یک کمک‌هزینه در قالب «وظیفه پاداش» منتشر می‌کند و KOLها محتوا ایجاد کرده و برای بررسی ارسال می‌کنند. آن‌ها تنها پس از تأیید می‌توانند پاداش دریافت کنند. این مکانیسم درباره ردیابی بلادرنگ و تسویه فوری نیست، بلکه بیشتر به مدل فرآیند «ارسال-بررسی» متمایل است.

این ساختار پتانسیل تبدیل شدن به یک پلتفرم باز را دارد: پلتفرم پشتیبانی تطبیق و زیرساخت را فراهم می‌کند، در حالی که پروژه‌های فردی مسئول عملیات رویدادهای خاص و مدیریت محتوا هستند. با پیوستن پروژه‌های بیشتر، استخر KOLها گسترش می‌یابد؛ و با رشد پایگاه تولیدکنندگان، تیم‌های پروژه نیز همکاران بالقوه بیشتری برای انتخاب دارند.

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

مدل «وبلاگ برند» به سبک کره‌ای

منبع: Revu

مدل «وبلاگ برند» کره‌ای مسیر «اول غربالگری، سپس مدیریت» را دنبال می‌کند، نه رویکرد «اول ایجاد محتوا، سپس بررسی» که در پلتفرم‌های پاداش دیده می‌شود. مؤسساتی مانند Revu بیش از یک دهه است که تحت این مدل فعالیت می‌کنند.

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

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

گسترش چند پلتفرمی

اگر X دیگر در دسترس نباشد، گزینه عملی بعدی چرخش به سمت پلتفرم‌هایی مانند YouTube، TikTok، Instagram و دیگران است. در واقع، در جامعه Web3، «حرکت فراتر از X» مدت‌هاست که یک توافق بوده است: برای دستیابی به رشد معنادار، لازم است از جامعه‌ای که عمدتاً از کاربران کریپتو-نیتیو تشکیل شده به کانال‌هایی که پایگاه کاربری گسترده‌تری در آن‌ها حضور دارند، گذار کرد.

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

با این حال، هزینه آن افزایش شدید پیچیدگی عملیاتی است. در X، فقط متن و تعاملات نیاز به بررسی دارند؛ در YouTube، زمان تماشا و کیفیت تولید مستقیماً بر عملکرد تأثیر می‌گذارند؛ در TikTok، سه ثانیه اول تقریباً موفقیت یا شکست را تعیین می‌کند؛ در Instagram، ارزیابی استوری‌ها، چیدمان و تکمیل بصری ضروری است. این امر تیم را ملزم می‌کند که توانایی‌های عملیاتی پلتفرم را داشته باشد یا ابزارها و فرآیندهای جدیدی ایجاد کند. علاوه بر این، سیاست‌های API پلتفرم و روش‌های بازیابی داده‌ها متفاوت هستند، که شبیه به «بازسازی سیستم» است.

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

مدل مدیریت KOL به سبک MCN

در مدل MCN وب ۲، ارزش برند KOLها ذاتاً ارزش تجاری آن‌ها را تعیین می‌کند؛ در Web3، این اثر حتی بارزتر است. روایت‌ها جریان وجوه را هدایت می‌کنند و تأثیر رهبران فکری به‌قدری تقویت می‌شود که می‌توانند مستقیماً بر قیمت توکن تأثیر بگذارند، به‌طوری که یک نظر واحد باعث نوسانات می‌شود.

برخی از پروژه‌های موفق InfoFi قبلاً گروهی بسیار فعال و منسجم از KOLها را ساخته‌اند. این KOLها به‌طور موقت از بیرون آورده نشده‌اند، بلکه به‌تدریج طی ماه‌ها در پلتفرم رشد کرده‌اند. در تضاد با MCNهای وب ۲ که به «کشف استعداد» مداوم متکی هستند، InfoFi احتمالاً این KOLهای موجود را حفظ کرده و مزیت پلتفرم را به سمت مدیریت و توزیع داده‌محور تغییر می‌دهد.

به اصطلاح MCN-سازی به این معنی است که مشارکت از «مشارکت داوطلبانه» آزاد به قرارداد و تعهد رسمی‌تر تبدیل خواهد شد. با بهره‌گیری از داده‌های طولانی‌مدت و شبکه‌های ارتباطی، قدرت چانه‌زنی پلتفرم در اکوسیستم Web3 نیز قوی‌تر خواهد بود و دستیابی به شرایط مشارکت و تخصیص منابع بهتر را آسان‌تر می‌کند.

با این حال، این مسیر تقاضاهای بالاتری را برای پروژه InfoFi ایجاد می‌کند: باید یک سیستم مدیریتی به‌اندازه کافی قوی وجود داشته باشد و «داده» به یک دارایی اصلی تبدیل خواهد شد. اگر پلتفرم بتواند از داده‌ها برای هدایت سرعت خروجی KOLها، جهت‌گیری محتوا و اثربخشی تبدیل استفاده کند و استراتژی Go-To-Market (GTM) حرفه‌ای‌تر و داده‌محورتری به پروژه ارائه دهد، این مدل ممکن است یک مانع رقابتی بلندمدت‌تر ایجاد کند.

InfoFi 2.0

فروپاشی InfoFi دو درس مهم برای کل اکوسیستم Web3 به جا گذاشت.

اولین مورد، طنز تمرکززدایی است: بسیاری از پروژه‌های Web3 در واقع به‌شدت به پلتفرم متمرکز X وابسته هستند و یک تصمیم واحد از سوی X برای فروپاشی کل سیستم کافی است.

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

منبع: X (@nikitabier)

آیا این بدان معناست که InfoFi پایان یافته است؟

نه کاملاً. چند پروژه‌ای که واقعاً به PMF (تناسب محصول با بازار) دست یافته‌اند ممکن است با بازسازی خود، مانند گذار به گسترش چند پلتفرمی، انجام تبلیغات منتخب‌تر یا ارتقا به مدل مدیریت KOL به سبک MCN، همچنان زنده بمانند.

با این حال، InfoFi 2.0 احتمالاً کوچک‌تر، قابل کنترل‌تر خواهد شد و تأکید بیشتری بر کیفیت محتوا خواهد داشت. این پروژه از «شکل پلتفرم» باز، بدون مجوز و مقیاس‌جو در گذشته به یک شبکه همکاری منتخب تبدیل خواهد شد که بیشتر شبیه به یک پلتفرم بازاریابی یکپارچه است که GTM محلی را پیش می‌برد و اجزایی مانند تبلیغات آفلاین را ترکیب می‌کند تا یک حلقه اجرایی کامل‌تر تشکیل دهد.

با این وجود، مسائل اساسی همچنان باقی هستند.

جوئل مون از Tiger Research House اشاره می‌کند که وقتی مکانیسم پاداش معرفی می‌شود، شرکت‌کنندگان ناگزیر به دنبال راه‌هایی برای «بازی» با سیستم خواهند بود که طراحی یک ساختار تشویقی عادلانه را تقریباً غیرممکن می‌کند. چنین رفتاری همچنان کیفیت محتوا را کاهش داده و یک حلقه بازخورد منفی ایجاد می‌کند که در نهایت به خود پلتفرم آسیب می‌رساند—چالش کلیدی که پروژه InfoFi باید به‌طور مستقیم با آن روبرو شود.

دیوید سوال اساسی‌تری مطرح کرد. او معتقد بود که گزاره ارزش توکن InfoFi، به‌جای ناشی شدن از عملکرد واقعی پلتفرم، بیشتر بر اساس «staking ایردراپ» و «ایمان به روایت» بوده است. با این حال، هر دوی این‌ها اهمیت عملی خود را از دست داده‌اند، بنابراین سوال مستقیماً مطرح شد: چرا سرمایه‌گذاران همچنان باید توکن InfoFi را بخرند؟

اگر InfoFi 2.0 می‌خواهد زنده بماند، باید پاسخ‌های روشنی به این سوالات ارائه دهد. پروژه‌ای که از دارندگان توکن جدا شده باشد، در نهایت برای دستیابی به پایداری واقعی تلاش می‌کند.

[لینک مقاله اصلی]