ローカライゼーション
多くの国に顧客を持つ企業にとって、Brazeの導入初期にローカライゼーションに取り組むことで、時間とリソースを節約できます。
仕組み
ロケール情報は、Braze SDK(自動)またはREST APIを使用して収集したデータに基づいて、ユーザーのプロファイルに保存されます。ロケールには言語と地域識別子が含まれます。この情報は、Brazeのセグメンテーションツールで国と言語の下から利用できます。
翻訳管理
翻訳を管理するために、以下のアプローチを検討してください。
すべてに1つのテンプレート
このアプローチでは、Liquidを使用して、Braze内の単一のテンプレートにローカライゼーションを適用します。送信後、ダッシュボードには集約されたCampaign分析が表示されます。ユーザーレベルのエンゲージメントは、カスタムSegmentファネルを使用して測定できます。たとえば、国と受信したCampaignフィルターを組み合わせることで測定できます。
| メリット | 考慮事項 |
|---|---|
| - 一元化されたアプローチ - メール作成時間の短縮、メールを複数回作成する必要がない |
- 手動でのレポート作成 - Campaignレポートには国別ではなく集約された指標が表示される - Liquidが期待どおりに表示されることを十分にテストする必要がある - 国の値の取得方法や設定した国の数によっては、各国のテストが難しい場合がある - タイムゾーンをまたいだ特定の時間での送信スケジュールが難しい - 国ごとに異なるコンテンツを送信したい場合に使いにくい |
国ごとに1つのテンプレート
このアプローチでは、テンプレートを異なる送信ロケールに分離します。送信後、ダッシュボードは各国ごとに送信分析をレポートし、下流のユーザーレベルのCurrentsイベントも特定のCampaignに紐付けられます。
- テンプレートは、メンテナンスとトラッキングの目的でタグを実装することで恩恵を受けます。
- Campaignsは、同じBrazeテンプレートとContent Blocks(Liquidを含むメールテンプレートなど)から設定を継承できます。
- 既存のCampaignsとテンプレートは複製して、より迅速な価値実現が可能です。
| メリット | 考慮事項 |
|---|---|
| - 複数のロケーションにスケーラブル - Braze内での国別収益レポート(Campaign単位など) - 国ごとに大幅に異なるコンテンツがある場合の柔軟性 |
- 戦略的な構造化が必要 - より多くの構築作業が必要(各国ごとに個別のCampaignsなど) |
すべてに1つのジャーニー
このアプローチでは、Canvasの基本とLiquidを使用して、各ユーザーのメッセージングを定義し、ローカライゼーションを処理します。
Canvasが送信された後、ダッシュボードには集約されたCanvas分析が表示されます。ユーザーレベルのエンゲージメントは、カスタムSegmentファネルを使用して測定できます。たとえば、国と受信したキャンバスステップフィルターを組み合わせることで測定できます。
| メリット | 考慮事項 |
|---|---|
| - 一元化されたアプローチ - メール作成時間の短縮 - メールを複数回作成する必要がない |
- 手動でのレポート作成 - Canvasレポートには国別ではなく集約された指標が表示される - Liquidが期待どおりに表示されることを十分にテストする必要がある - 国の値の取得方法や設定した国の数によっては、各国のテストが難しい場合がある - タイムゾーンをまたいだ特定の時間での送信スケジュールが難しい - 国ごとに異なるコンテンツを送信したい場合に使いにくい |
国ごとに1つのジャーニー
このアプローチでは、Canvasジャーニービルダーが、複数のCanvasコンポーネントを使用してユーザージャーニーを作成する柔軟性を提供します。これらのコンポーネントは、コンポーネントレベルおよびジャーニー全体のレベルで複製できます。
ローカライゼーションは以下の方法で実現できます:
- 国ごとに個別のCanvases。これにより、オーディエンスフィルターを使用してファネルの上部で複雑なユーザージャーニーが定義されます
- 国ごとのカスタムユーザージャーニー。オーディエンスパスを実装して、各ジャーニーで大規模にユーザーを直感的にセグメント化し、単一のCanvas内で各国ごとに個別のメッセージスレッドを作成します
送信後、ダッシュボードは顧客の現在のロケーションに基づいて、国別の動的な分析とユーザーレベルのCurrentsイベントを提供します。
| メリット | 考慮事項 |
|---|---|
| - Braze内での国別収益レポート(Canvas、バリアント、ステップ単位など) - 国ごとに大幅に異なるコンテンツがある場合の柔軟性 - 将来的にジャーニーの一部として他のチャネルを追加可能 |
- 戦略的な構造化が必要 - より多くの構築作業が必要(各国ごとに個別のメッセージステップなど) - 単一のCanvas内で各国ごとにカスタムの複雑なジャーニーがある場合、Canvasが大きくなり読みにくくなる可能性がある |
翻訳されたメッセージの送信
ユーザーの言語、ロケール、またはカスタム属性に基づいてパーソナライズされたメッセージを送信するには、以下のいずれかの方法を使用してください。
翻訳Liquidタグ(推奨)
Brazeは、単一のメッセージで異なる言語のユーザーをターゲットにするための {% translation salutation %}Hello!{% endtranslation %} Liquidタグをサポートしています。
詳しい手順については、翻訳タグの使用ガイドを参照してください。
代替アプローチ
メッセージ本文にコンテンツを手動で貼り付け、Liquidを使用して受信者に正しい言語を条件付きで表示できます。これを行うには:
- メッセージを作成し、Languageを選択して、選択した各言語のLiquid条件ロジックを生成します。
-
以下のLiquidテンプレートを使用してメッセージを構築できます。テンプレートを含む各フィールドについて、テンプレートの括弧付きセグメントの後にバリエーションを入力する必要があります。バリエーションは、その前の括弧内で参照されている言語コードに対応する必要があります。
1 2 3 4 5 6 7 8 9
{% if ${language} == 'en' %} This is a message in English from Braze! {% elsif ${language} == 'es' %} Este es un mensaje en español de Braze ! {% elsif ${language} == 'zh' %} 这是一条来自Braze的中文消息。 {% else %} This is a message from Braze! This will go to anyone who does not match the other specified languages! {% endif %}
- 送信前にユーザーのIDまたはメールアドレスを入力して、言語に応じてメッセージがどのように表示されるかを確認し、メッセージをテストしてください。
メッセージングには常に {% else %} ステートメントを含めることをお勧めします。ほとんどのユーザーは特定の言語のメッセージを見ますが、以下のユーザーにはこのテキストが表示されます:
- 言語が選択されていない
- Brazeがサポートしていない言語を使用している
- デバイスの言語が検出できない
BrazeのContent Blocksは再利用可能なコンテンツブロックです。ブロックが変更されると、そのブロックへのすべての参照が変更されます。たとえば、メールのヘッダーやフッターの更新はすべてのメールに反映されます。また、翻訳を格納するためにも使用できます。これらのブロックはREST APIを使用して作成および更新することもでき、ユーザーはプログラムで翻訳をアップロードできます。
ダッシュボードでCampaignを構築する際、Content Blocksはタグ {{content_blocks.${name_of_content_block}}} を使用して参照できます。これらのブロックには、オプション1に示すように各言語の条件ロジック内にすべての翻訳を含めることも、各言語ごとに個別のブロックを使用することもできます。
Content Blocksは翻訳管理プロセスとしても活用できます。翻訳が必要なコンテンツをContent Block内に格納し、取得、翻訳、更新します:
- ダッシュボードで「Needs Translation」タグ付きのContent Blockを手動で作成します。
- サービスが
/content_blocks/listエンドポイントを使用して、すべてのContent Blocksを毎晩取得します。 - サービスが
/content_blocks/infoエンドポイントを通じて各Content Blockの詳細を取得し、翻訳対象としてタグ付けされたブロックを確認します。 - 翻訳サービスが「Needs Translation」のすべてのContent Blocksの本文を翻訳します。
- サービスが
/content_block/updateエンドポイントにアクセスして、翻訳されたコンテンツを更新し、タグを「Translation Complete」に更新します。
カタログを使用すると、APIおよびCSVファイルを介してインポートされたJSONオブジェクトからデータにアクセスし、カスタム属性やカスタムイベントプロパティと同様にLiquidを通じてメッセージを充実させることができます。例:
以下のAPI呼び出しでカタログを作成します:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
curl --location --request POST 'https://your_api_endpoint/catalogs' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR-REST-API-KEY' \
--data-raw '{
"catalogs": [
{
"name": "translations",
"description": "My localization samples",
"fields": [
{
"name": "id",
"type": "string"
},
{
"name": "context",
"type": "string"
},
{
"name": "language",
"type": "string"
},
{
"name": "body",
"type": "string"
}
]
}
]
}'
以下のAPI呼び出しでアイテムを追加します:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
curl --location --request POST 'https://your_api_endpoint/catalogs/translations/items' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer YOUR-REST-API-KEY' \
--data-raw '{
"items": [
{
"id": "1",
"context": "1",
"language": "en",
"body": "Hey"
},
{
"id": "2",
"context": "1",
"language": "es",
"body": "Hola"
},
{
"id": "3",
"context": "1",
"language": "pt",
"body": "Oi"
},
{
"id": "4",
"context": "1",
"language": "de",
"body": "Hallo"
}
]
}'
以下の形式でCSVを作成します:
| id | context | language | body |
|---|---|---|---|
| 1 | 1 | en | Hey |
| 2 | 1 | es | Hola |
| 3 | 1 | pt | Oi |
| 4 | 1 | de | Hallo |
| 5 | 2 | en | Hey |
| 6 | 2 | es | Hola |
| 7 | 2 | pt | Oi |
| 8 | 2 | de | Hallo |
| 9 | 3 | en | Hey |
| 10 | 3 | es | Hola |
| 11 | 3 | pt | Oi |
| 12 | 3 | de | Hallo |
これらのカタログアイテムは、以下に示すパーソナライゼーション、またはデータのグループを作成できるセレクションを使用して参照できます。
1
2
3
{% catalog_items translations 1 %}
{{items[0].body}}
//returns “Hey”
多くのBrazeパートナーが、TransifexやCrowdinなどのローカライゼーションソリューションを提供しています。通常、ユーザーは社内チームや翻訳エージェンシーと併せてプラットフォームを使用します。翻訳はそこにアップロードされ、REST APIを介してアクセスできるようになります。これらのサービスはコネクテッドコンテンツも活用することが多く、ユーザーはAPIを介して翻訳を取得できます。
たとえば、以下のコネクテッドコンテンツ呼び出しはTransifexとCrowdinを呼び出して翻訳を取得し、{{${language}}}を活用して特定のユーザーに対する正しい翻訳を識別します。この翻訳はJSONブロック「strings」に保存され、参照されます。
1
2
{% connected_content https://www.transifex.com/api/2/project/example/resource/example/translation/{{${language}}}/strings :basic_auth semc :save strings %}
{{strings[0].translation}}
1
2
{% connected_content https://api.crowdin.com/api/project/braze-test/export-file?key=you_api_key&language={{${language}}}&file=test.json&export_translated_only=1 :save response %}
{{response.value_1}}
スプレッドシートに翻訳を格納し、以下のいずれかの方法を使用して関連する言語でメッセージを送信します。
翻訳エージェンシーと協力してGoogleスプレッドシートに翻訳を保存し、Brazeコネクテッドコンテンツを使用してこのコンテンツをクエリできます。メッセージを送信すると、各ユーザーの選択した言語に基づいて、関連する翻訳がCampaign本文に取り込まれます。
Google Sheets APIには、プロジェクトあたり100秒間に500リクエストの制限があります。コネクテッドコンテンツ呼び出しはキャッシュできますが、このソリューションは高トラフィックのCampaignにはスケーラブルではありません。
このオプションは、GoogleスプレッドシートをコネクテッドコンテンツでクエリされるJSONオブジェクトに変換する代替方法を提供します。スプレッドシートをSheetDB経由でJSON APIに変換することで、API呼び出しの頻度に応じて複数のサブスクリプションティアから選択できます。
スプレッドシートの構造はオプション4の手順に従いますが、SheetDBはオブジェクトをクエリするための追加フィルターも提供しています。
一部のユーザーは、SheetDBの検索メソッドをGETリクエスト呼び出しに実装して、{{${language}}} Liquidタグに基づいてJSONオブジェクトをフィルタリングし、大きな条件ブロックを構築する代わりに単一の言語の結果を自動的に返すことで、LiquidとConnected Blockの依存関係を減らしてSheetDBを実装することを好む場合があります。
ステップ1:Googleスプレッドシートのフォーマット
まず、言語が異なるオブジェクトになるようにGoogleスプレッドシートを構築します:
| language | title1 | body1 | title2 | body2 |
| en | Hey | 1 | Hey2 | 5 |
| es | Hola | 2 | Hola2 | 6 |
| pt | Oi | 3 | Oi2 | 7 |
| de | Hallo | 4 | Hallo2 | 8 |
ステップ2:コネクテッドコンテンツ呼び出しで言語Liquidタグを使用
次に、コネクテッドコンテンツ呼び出し内で {{${language}}} Liquidタグを実装します。SheetDBはスプレッドシートの作成時にsheet_idを自動生成します。
1
{% connected_content https://sheetdb.io/api/v1/[sheet_id]/search?language={{${language}}} :save result%}
ステップ3:メッセージのテンプレート化
最後に、Liquidを使用してメッセージをテンプレート化します:
1
2
{{result[0].title1}} //returns “Hey”
{{result[0].title2}} //returns “Hey2”
考慮事項
{{${language}}}フィールドはすべてのユーザーに対して定義されている必要があります。定義されていない場合、言語が設定されていないユーザーのフォールバックハンドラーとしてLiquid条件ブロックを含める必要があります。- Googleスプレッドシート内のデータモデリングは、メッセージオブジェクトを持つのではなく、言語駆動の縦方向の構造に従う必要があります。
- SheetDBは限定的な無料アカウントと複数の有料オプションを提供しており、Campaign戦略に基づいて検討する必要があります。
- コネクテッドコンテンツ呼び出しはキャッシュできます。API呼び出しの予測頻度を測定し、検索メソッドを使用する代わりにメインのSheetDBエンドポイントを呼び出す代替アプローチを検討することをお勧めします。