زبان جایگزین ایمیل مشخص میکند وقتی ترجیح مطمئنی در دست نیست مشتری چه نسخهای دریافت کند. مکان، نام یا تعامل قدیمی با پیامی دیگر همیشه برای شناسایی زبان درست کافی نیست. برای مخاطبان Shopify خود یک پیشفرض مفید انتخاب کنید، قاعده را صریح بنویسید و بررسی کنید همهٔ پیام از همان نسخه پیروی میکند.
وقتی ترجیح صریح هست از آن استفاده کنید
منبع اطلاعات زبان را روشن نگه دارید. ترجیحی که مشتری خودش برگزیده با مقدار حدسزدهشده یا فیلدی واردشده از دادهٔ قدیمی فرق دارد. بررسی کنید بهروزرسانی و مقدار خالی در دادههایتان چگونه رفتار میکند.
در Sendvio تخصیص زبان و رفتار جایگزین را برای همان کمپین یا خودکاری مشخص بررسی کنید. فرض نکنید مقدار خالی خودکار نسخهٔ موردنظر شما را برمیگزیند. آن را با رکوردی کنترلشده بیازمایید.
تصمیم جایگزین را با زبانی ساده بنویسید
سیاست مفیدی میتواند با ترجیح صریح و بهروز مشتری آغاز شود، نسخهٔ تأییدشدهٔ مطابق را انتخاب کند و در غیر این صورت از یک نسخهٔ کامل و مناسب فروشگاه بهعنوان پیشفرض استفاده کند. این سیاستی است که باید در تنظیمات پشتیبانیشده اجرا و آزمایش شود، نه فرضی دربارهٔ مسیریابی خودکار هر کمپین.
ترجیح ناشناخته را از ترجیح پشتیبانینشده جدا کنید. فیلد خالی یعنی مقداری ندارید؛ ثبت زبان ترجیحیای که هنوز برایش نسخه آماده نکردهاید یعنی اطلاعات مفیدی دارید اما فعلاً قادر به فراهمکردنش نیستید. شاید امروز هر دو به یک نسخهٔ جایگزین برسند، اما در برنامهریزی نباید یکی تلقی شوند.
زبان را از روی نام شخص حدس نزنید. حتی کشور هم ممکن است مقصد ارسال کالا را نشان دهد، نه زبان خواندن را. اگر در موقعیت مناسب از حدس استفاده میکنید، آن را چنین برچسب بزنید و از طریق فرایند پشتیبانیشده به ترجیح روشن مشتری اولویت دهید.
نسخهٔ جایگزین باید بهتنهایی مفید باشد
نسخهای مناسب مخاطب و فضای فروشگاه انتخاب کنید و مطمئن شوید پیام کامل است. وقتی نسخهٔ زبانی در دسترس نیست، از قالبی نیمهترجمهشده یا بلوک محتوای خالی استفاده نکنید.
از راهی مناسب برای بیان یا تغییر ترجیح زبانی مشتری از طریق فرایند پشتیبانیشده فراهم کنید. این کار را از اجازهٔ بازاریابی جدا نگه دارید: تغییر زبان نباید بیسروصدا فردی را که لغو اشتراک کرده دوباره مشترک کند.
مقدارهای خالی، قدیمی و ناموجود را بیازمایید
رکوردهای کنترلشدهای با زبان پشتیبانیشده، ترجیح خالی، مقدار پشتیبانینشده و ترجیح تازهتغییریافته بسازید. قالب واقعی ورود دادهٔ فروشگاه را هم لحاظ کنید. کدی مانند «en» و برچسبی مانند «English» شاید به نگاشت یکسان نیاز داشته باشند؛ بررسی کنید فیلدهای تنظیمشده چگونه تفسیر میشوند و خودبهخود آنها را برابر ندانید.
ایمیل حاصل و مسیر پس از کلیک را بررسی کنید. اگر نسخهٔ جایگزین یک زبان دارد ولی پیوندش مشتری را به پول یا بازاری ناموجود میبرد، جایگزین قابلاعتمادی نیست. هرجا بازار و زبان دو تصمیم متفاوتاند، واجد شرایط بودن بازار را از زبان جدا نگه دارید.
به حالتی فکر کنید که نسخهای موقتاً تأیید نشده است. نگهداشتن ارسال برای مخاطب درگیر شاید بهتر از جایگزینی بیسروصدای نسخهای برای پیشنهاد حساس یا پیچیده باشد. پیش از انتشار با مسئول وعدهٔ تجاری دربارهاش تصمیم بگیرید و بنویسید کدام مشتریان متأثرند.
مقصد را هم بررسی کنید
ایمیل جایگزین هنوز میتواند شکست بخورد اگر پیوند اصلی مشتری را به زبان یا بازار ناآشنایی ببرد. صفحهٔ فرود، موجودی محصول، واحد پول و مسیر پشتیبانی را یکجا بررسی کنید.
پس از انتشار، پاسخها و پرسشهای مربوط به زبان را بسنجید. اگر دریافتکنندگان زیادی نسخهٔ دیگری میخواهند، آن زبان را بر اساس نیاز واقعی مخاطب در اولویت بگذارید، نه اینکه یکباره همهٔ ترجمههای ممکن را اضافه کنید. نسخهٔ جایگزین حسابشده نقطهٔ شروعی قابلاعتماد برای رشد برنامهٔ زبانی است.
اندازهٔ مخاطبانی را که نسخهٔ جایگزین دریافت میکنند و دلیل ورودشان به آن را اندازه بگیرید. گروه بزرگِ بدون زبان شاید به مشکل نگاشت داده اشاره کند؛ رشد زبانهای پشتیبانینشده شاید افزودن نسخهٔ دیگری را توجیه کند. علت را اصلاح کنید، نه اینکه متن پیشفرض را پیدرپی برای جبران اطلاعاتی تغییر دهید که کمپین دریافت نکرده است.