از ایونت‌ها تا وضعیت مشتری: چرا Computed Traitها در CDXP مهم‌اند؟

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

یک مشتری ۴۲ روز است که خرید نکرده است.

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

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

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

این تفاوت مهم است.

جمع‌آوری ایونت‌ها به ما سابقه می‌دهد.

تصمیم‌گیری به وضعیت نیاز دارد.

اینجاست که Computed Traits به کار می‌آیند.

Computed Trait چیست؟

Computed Trait، ویژگی‌ای از مشتری است که از داده‌های دیگرِ موجود در پلتفرم به دست می‌آید.

مقدار آن به‌جای اینکه مستقیماً از CRM، SDK، API یا یک سیستم تراکنشی دریافت شود، از داده‌های موجود درباره‌ی رفتار یا پروفایل مشتری محاسبه می‌شود.

برای مثال:

days_since_last_purchase
orders_last_90_days
average_order_value
total_spend_12m
purchase_frequency
engagement_rate_30d
active_days_last_60d
preferred_category
category_affinity
days_since_last_meaningful_activity

داده‌های ورودی ممکن است از قبل به‌صورت ایونت یا ویژگی در سیستم وجود داشته باشند. Computed Trait با ترکیب، تجمیع، مقایسه یا تبدیل این ورودی‌ها، اطلاعات تازه‌ای درباره‌ی مشتری به دست می‌دهد.

به همین دلیل، موضوع صرفاً ذخیره‌کردن داده‌های بیشتر نیست.

• یک ایونت خرید پاسخ می‌دهد: «چه اتفاقی افتاد؟»
• یک ویژگی پروفایل ممکن است پاسخ دهد: «درباره‌ی این مشتری چه می‌دانیم؟»
• یک Computed Trait می‌تواند پاسخ دهد: «با توجه به همه‌ی آنچه تا امروز می‌دانیم، این مشتری حالا چه وضعیتی دارد؟»

این تمایز یکی از پایه‌های یک لایه‌ی هوشمندی مشتریِ کارآمد است.

ایونت‌ها شواهدند، نه تصمیم

فرض کنید ایونت‌های زیر برای یک مشتری خرده‌فروشی ثبت شده‌اند:

purchase_completed
purchase_completed
product_viewed
product_viewed
product_viewed
push_opened
product_viewed

این ایونت‌ها مفیدند، اما هنوز فقط مشاهدات‌اند.

یک متخصص مارکتینگ یا مدیر CRM معمولاً نمی‌خواهد صدها ردیف از تاریخچه‌ی ایونت‌ها را دستی بررسی کند و از آن‌ها نتیجه بگیرد. او به اطلاعاتی از این جنس نیاز دارد:

days_since_last_purchase = 42
orders_last_90_days = 3
average_order_value = 2.1x customer median
beauty_category_views_30d = 7
push_engagement_trend = declining

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

برای مثال:

IF
days_since_last_purchase > 30
AND historical_customer_value = high
AND category_affinity = skincare
AND push_reachability = true

THEN
include customer in a high-value reactivation audience

اصل موضوع، خود این قاعده نیست.

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

چهار نوع رایج Computed Trait

Computed Traitها می‌توانند جنبه‌های مختلفی از وضعیت مشتری را نشان دهند.

۱. ویژگی‌های تجمیعی

این ویژگی‌ها فعالیت مشتری را در یک بازه‌ی زمانی خلاصه می‌کنند.

برای مثال:

orders_last_30_days
total_spend_last_12_months
product_views_last_7_days
sms_clicks_last_90_days

عملیات محاسباتی آن‌ها معمولاً شمارش، مجموع، میانگین، کمینه، بیشینه یا شمارش مقادیر یکتا است.

این‌ها از ساده‌ترین Computed Traitها هستند، اما اغلب از کاربردی‌ترین‌ها هم هستند.

۲. تازگی تعامل و ویژگی‌های زمانی

این ویژگی‌ها نشان می‌دهند چه مدت از یک ایونت مهم برای مشتری گذشته است.

برای مثال:

days_since_last_purchase
days_since_last_session
days_since_last_cart
days_since_last_campaign_response

زمان سپری‌شده از آخرین ایونت (Recency) اهمیت ویژه‌ای دارد؛ چون گذر زمان وضعیت مشتری را تغییر می‌دهد، حتی وقتی خود مشتری هیچ کاری نمی‌کند.

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

۳. گرایش‌های رفتاری

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

برای مثال:

preferred_category = skincare
category_affinity_score = 0.81
preferred_purchase_day = friday
most_engaged_channel = push

ویژگی‌ای مثل گرایش به یک دسته‌ی محصول (Category Affinity) می‌تواند بر اساس بازدید از محصولات، جست‌وجوها، فعالیت در سبد خرید، خریدها، زمان سپری‌شده از این رفتارها یا وزن‌های متفاوتی که به هر رفتار داده می‌شود، محاسبه شود.

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

۴. ویژگی‌های نسبی یا مقایسه‌ای

گاهی جایگاه نسبی مشتری از مقدار مطلق یک شاخص کاربردی‌تر است.

برای مثال:

customer_value_percentile = 93
purchase_frequency_vs_previous_period = -28%
engagement_vs_90d_baseline = -41%

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

Computed Traitها با امتیازهای پیش‌بینی متفاوت‌اند

هرچه CDXPها به سمت هوش مصنوعی و تصمیم‌گیری حرکت می‌کنند، این تمایز مهم‌تر می‌شود.

این سه مقدار را در نظر بگیرید:

days_since_last_purchase = 42
churn_probability = 0.78
next_best_action = retention_offer

ممکن است هر سه در نهایت کنار هم در پروفایل یک مشتری نمایش داده شوند، اما هرکدام به لایه‌ی متفاوتی از هوشمندی تعلق دارند.

days_since_last_purchase یک Computed Trait است.
این مقدار با محاسبه‌ای قطعی از داده‌های معلوم به دست می‌آید.

churn_probability یک امتیاز پیش‌بینی است.
این مقدار معمولاً خروجی یک مدل آماری یا یادگیری ماشین است.

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

بنابراین، یک معماری کارآمد بیشتر چنین مسیری دارد و در آن هر مقداری که از داده‌های دیگر به دست می‌آید «هوش مصنوعی» نامیده نمی‌شود:

این تفکیک از نظر عملیاتی هم مهم است. بررسی، توضیح، اعتبارسنجی و اعمال ضوابط حاکمیت داده بر Computed Traitها اغلب ساده‌تر از خروجی مدل‌هاست.

تفاوت Computed Trait با بخش‌بندی

Computed Trait با یک بخش از مشتریان (Segment) هم یکی نیست.

این مقدار را در نظر بگیرید:

days_since_last_purchase = 42

این، ویژگی یک مشتری است.

حالا این شرط را ببینید:

days_since_last_purchase > 30
AND
average_order_value > 5,000,000

این، تعریف یک بخش است که چندین مشتری را بر اساس ویژگی‌هایشان انتخاب می‌کند.

جدا نگه‌داشتن این دو مفهوم، امکان‌های زیادی ایجاد می‌کند.

همان ویژگی days_since_last_purchase می‌تواند بعداً در موارد مختلف استفاده شود:

• یک بخش برای پیشگیری از ریزش مشتریان
• یک بخش برای بازفعال‌سازی مشتریان VIP
• شرط انشعاب در مسیر تعامل مشتری
• پروفایل مشتری
• گزارش تحلیلی
• قاعده‌ی احراز شرایط
• یکی از ویژگی‌های ورودی مدل پیش‌بینی

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

یک Computed Trait یک‌بار محاسبه و همه‌جا بازاستفاده می‌شود. بخش‌بندی فقط یکی از مکان‌های استفاده از آن است. اصل بازاستفاده

چرا اهمیت این موضوع از اتوماسیون مارکتینگ فراتر می‌رود؟

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

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

تفاوت مهم‌تر این است که محاسبات مربوط به مشتری در کجای سیستم قرار می‌گیرند.

در یک CDXP، وضعیت به‌دست‌آمده از داده‌های مشتری می‌تواند متعلق به خود لایه‌ی داده‌ی مشتری.

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

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

برای مثال:

category_affinity = home_appliances

می‌تواند در این بخش‌ها به کار برود:

• ابزار ساخت بخش‌های مخاطبان (Segment Builder)
• ابزار ساخت مسیرهای تعامل مشتری (Journey Builder)
• شخصی‌سازی کمپین‌ها
• هدف‌گیری در Retail Media
• شخصی‌سازی در وب‌سایت
• تحلیل
• منطق پیشنهاددهی
• یک مقصد خارجی یا API

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

Computed Trait زمانی کاربرد دارد که بتوان دوباره از آن استفاده کرد

از اینجا به یک اصل مهم در طراحی محصول می‌رسیم.

عددی که محاسبه شده اما در یک گزارش پنهان مانده است، لزوماً یک Computed Trait کاربردی نیست.

برای اینکه یک ویژگی وارد عملیات شود، بهتر است چند خصوصیت داشته باشد.

تعریف روشن

کاربر باید دقیقاً بداند آن ویژگی چه چیزی را نشان می‌دهد.

برای مثال:

average_order_value_90d

از این نام روشن‌تر است:

customer_value

مگر اینکه برای خود customer_value فرمول مشخص و مدونی تعریف شده باشد.

بازه‌ی زمانی مشخص برای محاسبه

یک محاسبه‌ی یکسان در بازه‌های ۷، ۳۰، ۹۰ یا ۳۶۵ روزه می‌تواند معناهای کاملاً متفاوتی پیدا کند.

بنابراین، بازه‌های زمانی باید صریح و مشخص باشند.

روش و زمان‌بندی به‌روزرسانی

بعضی ویژگی‌ها فقط به محاسبه‌ی مجدد روزانه نیاز دارند.

بعضی دیگر ممکن است به به‌روزرسانی نزدیک به لحظه نیاز داشته باشند.

برای مثال:

lifetime_orders

ممکن است با به‌روزرسانی دوره‌ای هم کارایی خود را حفظ کند. اما:

minutes_since_cart_abandonment

ممکن است فقط زمانی ارزش داشته باشد که سریع به‌روز شود.

مشخص‌بودن موجودیتی که ویژگی به آن تعلق دارد

بیشتر Computed Traitها به پروفایل مشتری تعلق دارند، اما همین الگو می‌تواند فراتر از مشتری هم به کار برود.

یک پلتفرم ممکن است در ادامه برای این موجودیت‌ها هم ویژگی محاسبه کند:

• محصولات
• تبلیغ‌دهندگان
• کمپین‌ها
• بخش‌های مخاطبان
• جایگاه‌های نمایش
• حساب‌ها

حاکمیت داده و تبیین‌پذیری

کاربر باید بتواند به این پرسش‌ها پاسخ دهد:

• این ویژگی از چه داده‌هایی استفاده می‌کند؟
• چه بازه‌ی زمانی را در نظر می‌گیرد؟
• آخرین بار چه زمانی به‌روز شده است؟
• با کدام تعریف یا نسخه محاسبه شده است؟
• در حال حاضر کجاها استفاده می‌شود؟

با پیچیده‌ترشدن پلتفرم‌ها، ردیابی منشأ داده و مسیر محاسبه‌ی آن (Lineage) اهمیت بیشتری پیدا می‌کند. اگر تعریف یک Computed Trait بدون اطلاع تغییر کند، ممکن است هم‌زمان عضویت مشتریان در بخش‌های مخاطبان، نحوه‌ی اجرای کمپین‌ها، تحلیل‌ها و خروجی مدل‌ها را تغییر دهد.

از Computed Traitها تا شناخت بهتر وضعیت مشتری

فرصت اصلی در ساختن صدها شاخص دلخواه نیست.

فرصت اصلی این است که مشخص کنیم کدام وضعیت‌های قابل‌محاسبه برای کسب‌وکار اهمیت دارند.

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

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

برای یک سرویس پخش آنلاین محتوا ممکن است این موارد مهم باشند:

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

برای یک محصول فین‌تک ممکن است این موارد مهم باشند:

• دفعات تراکنش
• غیرفعال‌بودن کیف پول
• تغییرات موجودی
• تنوع خدماتی که مشتری استفاده می‌کند
• الگوی پرداخت‌های تکرارشونده

برای یک مارکت‌پلیس ممکن است این موارد مهم باشند:

• دفعات خرید خریدار
• گرایش به فروشنده
• تنوع دسته‌های مورد استفاده
• نسبت جست‌وجو به خرید
• میزان واکنش به پیشنهادهای ترویجی

بنابراین، معمولاً با این پرسش نمی‌توان Computed Traitهای مناسب را پیدا کرد:

پایگاه داده‌ی ما چه محاسباتی می‌تواند انجام دهد؟

پرسش بسیار بهتر این است:

چه چیزی درباره‌ی وضعیت فعلی مشتریانمان هست که بارها خواسته‌ایم بدانیم؟

این پرسش از تصمیم کسب‌وکار شروع می‌کند و از آنجا به داده‌های موردنیاز می‌رسد.

Computed Traitها در بین‌وبان

در بین‌وبان، Computed Traitها برای تبدیل داده‌های موجود و سابقه‌ی رفتاری مشتری به ویژگی‌هایی قابل‌استفاده‌ی مجدد طراحی شده‌اند.

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

یک خرده‌فروشی ممکن است این ویژگی‌ها را محاسبه کند:

days_since_last_purchase
orders_last_90_days
average_order_value
category_affinity

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

یک تیم CRM ممکن است این ویژگی‌ها را محاسبه کند:

engagement_rate_30d
engagement_change_vs_previous_30d
preferred_channel

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

پرسش بعدی معمولاً جذاب‌ترین پرسش است

Computed Traitها با یک ایده‌ی ساده شروع می‌شوند:

داده‌ی خام ثبت می‌کند چه اتفاقی افتاده است. وضعیت به‌دست‌آمده از آن داده کمک می‌کند بفهمیم آن اتفاق امروز چه معنایی دارد.

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

پلتفرم می‌تواند از پرسش «این مشتری چه کارهایی کرده است؟» به پرسش «این مشتری در چه وضعیتی است؟» برسد، سپس به «احتمالاً در ادامه چه اتفاقی می‌افتد؟» و در نهایت به «ما در قبال آن چه کار کنیم؟»

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

پس در تقریباً هر کسب‌وکاری که با مشتری سروکار دارد، می‌توان این پرسش را مطرح کرد:

چه چیزی درباره‌ی مشتریانتان بوده که بارها خواسته‌اید بدانید و با خود گفته‌اید: «کاش می‌توانستیم این را محاسبه کنیم»؟

به احتمال زیاد، پاسخ همین پرسش باید به یک Computed Trait تبدیل شود.