در قسمت اول، نوشتم که در تجارت Agent-محور ممکن است فروشگاه سفارش را نگه دارد ولی مالکیت تصمیم را از دست بدهد. حالا میخواهم یک لایه پایینتر بروم؛ به جایی که به نظرم خسارت زودتر و بیسروصداتر اتفاق میافتد: پایگاه دادهی مشتری.
بگذارید با یک مثال ساده شروع کنم و در طول مقاله به آن برگردم.
کاربری از Agent خود میخواهد برای تولد فرزندِ یکی از دوستانش هدیهای پیدا کند. Agent دهها اسباببازی را بررسی میکند، چند گروه سنی را مقایسه میکند، نقدها را میخواند و در نهایت یک محصول را میخرد.
فردای آن روز پلتفرم فروش چه چیزی دربارهی این کاربر میداند؟
پاسخ مستقیم
Agent نه مشتری است و نه نسخهی دیجیتال او؛ بازیگری مستقل است که باید با رابطهای محدود و زماندار به مشتری وصل شود، نه با او ادغام شود. ادغام رفتار Agent در پروفایل مشتری رضایت، انتساب فروش، بخشبندی مخاطبان و مدلهای پیشبینی را آلوده میکند.
اگر تمام رفتار Agent را مثل رفتار مستقیم انسان وارد پروفایل مشتری کند، به این نتیجهها میرسد: کاربر به اسباببازی کودک علاقه دارد، احتمالاً بچهای در آن گروه سنی دارد و گزینهی خوبی برای خریدهای مشابه است. بعد او را وارد یک گروه مخاطب هدف میکند، پیام شخصیسازیشده میفرستد و مدلهای پیشبینیاش را با همین داده تغذیه میکند.
هیچکدام از این نتیجهها درست نیست. کاربر بچه ندارد. به اسباببازی علاقه ندارد. و احتمالاً تا همین موقع در سال آینده هم دوباره سراغ این دسته نمیرود.
این مثال ساده یکی از سختترین مسائل دادهی مشتری در سالهای پیشروست: وقتی بازیگر واقعیِ یک تعامل Agent است، چه بخشی از رفتارش متعلق به پروفایل انسان است؟
پاسخ من این است: Agent باید به مشتری وصل شود اما نباید با او یکی شود.
Agent با «دوقلوی دیجیتال» فرق دارد
Digital Twin یا دوقلوی دیجیتال، یک بازنمایی است. کارش توصیف یا شبیهسازی وضعیت و ترجیحات یک شخص است.
Agent عمل میکند. ممکن است از مدلی شبیه دوقلوی دیجیتال استفاده کند ولی خودش آن نیست. ابزار دارد، با محیط بیرون تعامل میکند و در محدودهی اختیاری که گرفته تصمیم میگیرد.
این تفاوت فقط مفهومی نیست؛ در معماری سیستم اثر میگذارد. دوقلوی دیجیتال بخشی از مدل شناخت ما از مشتری است. Agent یک بازیگر مستقل است که هویت، ارائهدهنده، توانمندی، مجوز و سابقهی عمل خودش را دارد.
برگردیم به همان خرید هدیه. چند واقعیت را ببینید:
- آن Agent ممکن است فقط برای یک مأموریت دهدقیقهای ساخته شده باشد و پس از آن دیگر وجود نداشته باشد.
- ممکن است بین چند عضو خانواده یا کارکنان یک شرکت مشترک باشد.
- همان کاربر ممکن است برای سفر، امور مالی و کار سازمانی Agentهای کاملاً متفاوتی داشته باشد.
- خرید ممکن است برای شخص دیگری انجام شده باشد که در مثال ما دقیقاً همینطور است.
- بخشی از تصمیم Agent محصولِ محدودیتهای ارائهدهنده، مدل و ابزارهای اوست، نه ترجیح کاربر.
- بخش بزرگی از آن دهها محصول بررسیشده را هیچ انسانی ندیده است.
در بهترین حالت Agent یک نمایندهی مأموریتمحور از قصد کاربر است؛ محدود، موقت و وابسته به هدف.
چهار موجودیت که باید از هم متمایز بمانند
مدل هویت در تجارت سنتی حول یک سؤال ساخته شده بود: این کوکی، شناسهی دستگاه، شماره تلفن و شمارهی مشتری متعلق به کدام فرد است؟
در تجارتی که هم انسان و هم ماشین در آن عمل میکنند این سؤال کافی نیست. هر تعامل باید دستکم چهار چیز را از هم جدا نگه دارد.
- بازیگر (Actor): چه موجودیتی عمل را انجام داده؟ انسان، Agent، خزندهی موتور جستوجو، ابزار خودکار یا سیستم سازمانی؟
- صاحب اختیار (Principal): این عمل با اجازهی چه انسان یا سازمانی انجام شده؟
- ذینفع (Beneficiary): نتیجه برای چه کسی است؟ صاحب حساب، عضو دیگری از خانواده، گیرندهی هدیه یا یک واحد سازمانی؟
- مأموریت (Mission): Agent برای چه هدف مشخصی عمل میکند؟
در مثال ما بازیگر یک Agent است، صاحب اختیار کاربر است، ذینفع بچهی یک نفر دیگر است و مأموریت یک خرید هدیهی یکباره. اگر سیستم فقط صاحب اختیار را ثبت کند، سه مورد دیگر از دست میروند و پروفایل از همان ابتدا تصویری نادرست میسازد.
نمونهی سازمانیاش هم دقیقاً همین شکل است: مدیر خرید به Agent شرکت اجازه میدهد برای یک شعبه کالا سفارش دهد، پرداخت از حساب شرکت انجام میشود و مصرفکننده کارکنان آن شعبهاند. سه موجودیت متفاوت و یک تراکنش.
مدل درست رابطه این است:
Agent -- acts_for [scope, purpose, expiry] --> Principalیعنی Agent هویت مستقل خودش را نگه میدارد و رابطهاش با صاحب اختیار در یک Mandate ثبت میشود؛ یک اختیار تفویضشدهی مشخص که دامنه، هدف، بودجه، محدودیت و تاریخ انقضا دارد.
چرا ادغام کامل خطرناک است؟
در پلتفرمهای دادهی مشتری فرایندی هست به اسم Identity Resolution که تلاش میکند شناسههای پراکندهی متعلق به یک شخص را با اطمینان کافی به یک پروفایل وصل کند. برای شماره تلفن، ایمیل و شمارهی مشتری منطق درستی است. برای Agent نتیجهی معکوس میدهد.
اگر Agent و انسان کاملاً در هم ادغام شوند:
- علاقههای موقت به ویژگیهای دائمی تبدیل میشوند (همان «این آدم بچه دارد»)
- رفتار چند صاحب اختیار در یک پروفایل مخلوط میشود
- سقف نمایش تبلیغ و فهرست حذفشدهها اشتباه عمل میکنند
- گروههای مخاطب تبلیغاتی با دادهی مأموریتمحور تغذیه میشوند
- مرز بین تصمیم انسان و جستوجوی مستقل Agent در انتساب فروش محو میشود
- رضایت یک کاربر ممکن است به Agent یا مأموریت یا فرد دیگری سرایت کند
- مدلهای پیشبینی بهجای رفتار مشتری سیاستهای ارائهدهندهی Agent را یاد میگیرند
مورد آخر اهمیت ویژهای دارد. مدل شما ظاهراً سلیقهی مشتری را یاد میگیرد، اما در واقع در حال یادگیری الگوریتم رتبهبندی یک شرکت دیگر است.
و بدتر اینکه این آلودگی بهسادگی برگشتپذیر نیست. وقتی هزاران تعامل اشتباه وارد ویژگیها و دستهبندیها و سناریوهای ارتباطی شد، حذف شناسهی Agent مشکل را حل نمیکند. باید سراغ همهی استنتاجهایی بروید که از آن داده ساخته شدهاند؛ درحالیکه معمولاً مشخص نیست این استنتاجها کجا استفاده شدهاند.
اما رفتار Agent را هم کنار نگذارید
راهحل این نیست که رفتار Agent را کنار بگذاریم. Agent میتواند سیگنال قدرتمندی از قصد باشد. مسئله این است که هر سیگنال با وزن، منشأ و طول عمر درست ذخیره شود.
قاعدهی من ساده است: هرچه سیگنال به تصمیم یا تأیید انسان نزدیکتر است، وزن و ماندگاری بیشتری دارد. هرچه به جستوجوی مستقل Agent نزدیکتر است، باید موقتتر و محدودتر بماند.
در عمل یعنی این:
خرید قطعی و تحویلشده میتواند وارد تاریخچهی تراکنش صاحب اختیار شود بهشرطی که ثبت شود بازیگر واقعی یک Agent بوده و اگر ذینفع شخص دیگری است این هم حفظ شود. در مثال ما سفارش ثبت میشود ولی با برچسبی که میگوید «خرید هدیه، ذینفع دیگری».
تأیید صریح انسان — انتخاب مشخص، ذخیرهی محصول، سبد تأییدشده — سیگنال پرقدرتی است و با اطمینان بالا وارد پروفایل میشود.
فهرست کوتاهی که Agent ساخته بهعنوان قصد موقت نگه داشته میشود، مشروط به اینکه ارائهدهنده، مأموریت، میزان اطمینان و تاریخ انقضا مشخص باشد.
گشتوگذار و مقایسهی اولیه، یعنی بررسی همان دهها اسباببازی، در پروفایل مأموریت میماند و هرگز وارد ویژگیهای بلندمدت انسان نمیشود.
پیشنهاد حمایتشدهای که Agent دیده مواجههی انسانی نیست و بهتنهایی نباید مبنای بازاریابی مجدد برای انسان شود.
استنتاج ساختهی Agent بدون منشأ، هدف و تاریخ انقضا نباید به ویژگی دائمی مشتری تبدیل شود.
پروفایل آینده یک رکورد تخت نیست
پروفایل مشتری سنتی معمولاً مجموعهای از شناسهها، ویژگیها، دستهبندیها و یک خط زمانی رفتار است. در محیطی که انسان و ماشین کنار هم عمل میکنند این مدل باید لایهدار شود:
- پروفایل صاحب اختیار: هویت، رضایت، ویژگیها و تاریخچهی انسان یا سازمان
- پروفایل Agent: ارائهدهنده، نسخه، توانمندی، مجوز، وضعیت احراز و سابقهی عمل
- اختیار تفویضشده: دامنهی اختیار، هدف، بودجه، سیاست تأیید و تاریخ انقضا
- پروفایل مأموریت: قصد، محدودیتها، دسته، ذینفع و طول عمر مأموریت
- منشأ ایونت: چه بازیگری، از چه منبعی و در چه زمینهای این ایونت را ساخته
- نتیجه: سفارش، پرداخت، تحویل، لغو و مرجوعی
این لایهها میتوانند در یک گراف هویت به هم وصل باشند ولی نباید در یک رکورد واحد و بدون حفظ تفاوتها ادغام شوند.
سه مجوزی که یکی نیستند
خطرناکترین سادهسازی این است که اجازهی خرید Agent را معادل رضایت کاربر برای استفاده از داده بدانیم.
رضایت میگوید داده برای چه هدفی قابلپردازش است؛ ارائهی سرویس، تبلیغات شخصیسازیشده، تحلیل، یا اشتراک با شریک تجاری.
تفویض اختیار (Delegation) میگوید Agent چه کاری میتواند به نمایندگی از صاحب اختیار انجام دهد؛ جستوجو، مقایسه، ساخت سبد، پرداخت، مدیریت سفارش.
مجوز تراکنش (Transaction Authorization) میگوید کدام معاملهی مشخص با چه مبلغ و چه فروشندهای مجاز شده است.
کاربر مثال ما اجازه داده یک هدیه خریده شود. اجازه نداده پروفایلش غنیسازی شود، در گروه مخاطب اسباببازی قرار بگیرد یا قصدش به یک تبلیغدهنده منتقل شود. این سه چیز کاملاً جدا هستند و باید جدا ثبت شوند.
استانداردها دارند در همین جهت حرکت میکنند. پروتکل AP2 در گوگل از اختیارهای امضاشده برای ثبت دستور و محدودیتهای کاربر استفاده میکند. Delegated Payment در OpenAI مجوز پرداخت را یکبارمصرف، محدود به مبلغ و دارای انقضا مدل میکند. Visa Trusted Agent Protocol بین Agent معتبر، کاربر احرازشده و اختیار خرید تفاوت میگذارد؛ هرچند ویزا خودش صریح میگوید هنوز در مرحلهی توسعه است.
اصل مشترک هر سه یکی است: اختیار Agent باید محدود، قابلاثبات و قابللغو باشد. رضایت نیز باید جدا و وابسته به هدف بماند.
حداقل اطلاعاتی که باید در هر ایونت ثبت شود
اگر بخواهم عملیترین بخش این مقاله را در یک جدول خلاصه کنم، به این موارد میرسم. هر تعاملی که Agent در آن نقش دارد باید این اطلاعات را حمل کند:
| فیلد | چه چیزی را ثبت میکند | چرا لازم است |
|---|---|---|
| نوع بازیگر | انسان، Agent، خزنده، ابزار خودکار و سیستم سازمانی | جلوگیری از ورود ماشین به آمار انسانی |
| شناسه و ارائهدهندهی Agent | این Agent کیست و متعلق به چه پلتفرمی است | تشخیص سوگیری ارائهدهنده در رفتار |
| وضعیت احراز | آیا هویت و اختیار Agent تأیید شده؟ | مرز بین Agent معتبر و ابزار ناشناس |
| صاحب اختیار | این عمل با اجازهی چه کسی انجام شده | اتصال بدون ادغام |
| ذینفع | نتیجه برای چه کسی است | جلوگیری از نسبتدادن ترجیحات گیرندهی هدیه به خریدار |
| مأموریت و هدف | Agent برای چه کاری فعال شده | نگهداشتن سیگنال در دامنهی خودش |
| ارجاع به اختیار | این عمل به کدام Mandate متصل است | اثباتپذیری و امکان لغو |
| حضور انسان | تأیید همزمان انسان بوده یا نه؟ | تعیین وزن سیگنال |
| ارگانیک یا حمایتشده | آیا این نمایش در ازای پرداخت انجام شده است؟ | شفافیت و صحت انتساب |
| تاریخ انقضای سیگنال | این ایونت تا چه زمانی معتبر است؟ | جلوگیری از تبدیل قصد موقت به ویژگی دائمی |
| قاعدهی ورود | با چه منطقی وارد پروفایل شد؟ | امکان بازگشت در صورت خطا |
هدف جمعآوری حداکثری داده نیست. هدف، ثبت اطلاعات کافی دربارهی منشأ داده است تا بعداً آن را اشتباه تفسیر نکنیم.
و یک نکته که معمولاً فراموش میشود: هر تصمیم اتصال یا انتقال سیگنال باید قابلبازگشت باشد. باید بتوانید بپرسید «این ویژگی از کجا آمد؟» و بتوانید حذفش کنید بدون اینکه کل پروفایل را بازسازی کنید. مدل دادهی Verifiable Credentials در W3C — استانداردی برای ادعاهایی که میشود صحتشان را مستقلاً راستیآزمایی کرد — یکی از زیرساختهای ممکن است اما فناوری ثبت و اثبات مجوز بهتنهایی کافی نیست. سیستم داده باید بداند این ادعا برای چه هدفی و تا چه زمانی قابلاستفاده است.
چرا این مسئله در ایران حادتر است؟
بازار ایران چند ویژگی دارد که آن را بیشتر از بازارهای بالغ در معرض ادغام اشتباه میگذارد. این ویژگیها پیش از ورود Agentها هم وجود داشتهاند.
حسابهای مشترک خانوادگی رایجاند. یک حساب دیجیکالا یا اسنپمارکت که پدر، مادر و بچهها از آن استفاده میکنند کاملاً عادی است. پروفایلی که از آن ساخته میشود از همین حالا ترکیبی از چند نفر است.
شماره تلفن شناسهی غالب است. در بازارهای دیگر ایمیل، کوکی و شناسهی دستگاه سیگنالهای متعدد و گاهی متناقض میدهند که سیستم را وادار به احتیاط میکند. در ایران شماره تلفن یک کلید قطعی و پرقدرت است. هر دادهای که به آن متصل شود، با اطمینان بالا ادغام میشود؛ چه این اتصال درست باشد و چه غلط.
استاندارد مشترکی برای اختیار تفویضشده وجود ندارد. نه پروتکلی، نه توافقی و نه حتی زبان مشترکی برای اینکه بگوییم این خرید با چه اختیاری انجام شده.
حالا Agent را به این ترکیب اضافه کنید. فروشگاهی که همهی فعالیتها را به صاحب شماره تلفن نسبت میدهد، این موارد را در یک پروفایل واحد مخلوط میکند: رفتار خود کاربر، رفتار بقیهی اعضای خانواده، جستوجوی مستقل Agent و خریدی که اصلاً برای شخص دیگری بوده.
بعد روی این پروفایل، گروه مخاطب میسازد و بودجهی تبلیغات خرج میکند.
مسئله پیش از آنکه فنی باشد، به تعریف مربوط است. ما هنوز درست تعریف نکردهایم «مشتری» یعنی چه کسی.
هویت در تجارت آینده، رابطه است نه رکورد
برگردیم به همان خرید هدیه. Agent ترجیحات کاربر را میدانست، برایش گشت و در محدودهی اختیارش خرید کرد. هیچکدام از اینها Agent را به خودِ کاربر تبدیل نمیکند.
پروفایل آینده هم نباید انباری از هر تعاملی باشد که بهنوعی به حساب مشتری چسبیده. باید بتواند بین رفتار مستقیم انسان، رفتار مأموریتمحور Agent، اختیار دادهشده، رضایت معتبر و نتیجهی قطعی تفاوت بگذارد.
در تجارت انسانمحور کار هویت عمدتاً یکیکردن شناسههای پراکنده بود. از این به بعد بلوغ هویت در توانایی حفظ تفاوتهاست.
در قسمت آخر این سری سراغ پول میروم: اگر Agent روی تبلیغ کلیک کند، بابت چه چیزی و به چه کسی باید پول داد؟
گام بعدی