Skip to content

ローカライゼーション

Braze は SDK を統合した後、ユーザーのデバイスからロケール情報を自動的に収集します。ロケールには、言語と地域識別子が含まれています。この情報は、Braze セグメンテーションツールの [] と [言語] で確認できます。

プラットフォームに応じたロケールの受信方法に関する技術的な詳細については、次の iOS および Android/FireOS のリソースを参照してください。

多くの国に顧客を持つ企業の場合、Braze ジャーニーの早い段階でローカライゼーションを処理することで、会社の時間とリソースを節約できます。この記事では、複数のキャンペーンとキャンバスにわたるさまざまなオーケストレーションアプローチの利点と、ユーザーがメッセージングでパーソナライゼーションを処理できるさまざまな方法を示します。

オーケストレーション

Campaign

「全ユーザーに 1 つのテンプレート」というアプローチでは、Liquid を使用して Braze の 1 つのテンプレートにローカライゼーションが適用されます。送信後、ダッシュボードは集計されたキャンペーン分析を提供する。ユーザーレベルのエンゲージメントは、例えば受信キャンペーンのフィルターを組み合わせるなど、カスタムのセグメントファネルを使用して測定できます。

国ごとに1つのテンプレート」というアプローチは、送信ロケールごとにテンプレートを分けている。送信後、ダッシュボードは国別に送信分析を報告し、下流のユーザーレベルのCurrentsイベントも特定のキャンペーンに関連付けられる。

キャンバス

「全ユーザーに 1 つのジャーニー」というアプローチでは、ローカライゼーションがキャンバスジャーニーと Liquid 内で処理され、各ユーザーへのメッセージングを定義します。

キャンバスが送信された後、ダッシュボードには集計されたキャンバス分析が表示され、ユーザーレベルのエンゲージメントは、カスタムのセグメントファネル (受信キャンバスステップのフィルターの組み合わせなど) で測定できます。

「国ごとに 1 つのジャーニー」というアプローチでは、キャンバスジャーニービルダーを使って複数のキャンバスコンポーネントを介してユーザージャーニーを柔軟に作成できます。これらのコンポーネントは、コンポーネントレベルおよびジャーニー全体で複製できます。

ローカライゼーションは、次の方法で実行できます。

  • 国ごとにキャンバスを分けることで、複雑なユーザージャーニーがオーディエンスフィルターを使用してファネルの一番上に定義されるようにする。
  • 国ごとに特注のユーザージャーニーを作成し、Audience Pathsを実装することで、1つのCanvasに国ごとに個別のメッセージスレッドを作成することで、ジャーニーごとに大規模にユーザーを直感的にセグメント化する。

送信後、ダッシュボードには顧客の現在地に基づいて、国ごとおよびユーザーレベルの Currents イベント内のダイナミックな分析が表示されます。

パーソナライゼーション

オプション 1: 手動エントリ

手動エントリでは、コンテンツをメッセージの本文に手動で貼り付け、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 %}

これは、上記の形式を使用するか、Braze ダッシュボードを使用して実行できます。

  1. メッセージを作成するときに、[言語] ボタンを選択すると、選択した言語ごとに Liquid の条件付きロジックが生成されます。
  2. テンプレートテキストをメッセージに挿入したら、言語ごとに異なるバリエーションを入力します。テンプレートを使用するフィールドごとに、テンプレートの中括弧内のセグメントの後にバリエーションを入力する必要があります。バリエーションは、その前の中括弧で参照されている言語コードに対応していなければなりません。
  3. 送信前にユーザーの ID またはメールアドレスを入力してメッセージをテストし、言語に応じてメッセージがどのように表示されるかを確認します。

オプション 2: コンテンツブロック

Braze のコンテンツブロックは再利用が可能なコンテンツのブロックです。ブロックが変更されると、そのブロックへの参照もすべて変更される。たとえば、メールヘッダーまたはフッターの更新は、すべてのメールまたは翻訳に反映されます。これらのブロックは REST API を使用して作成および更新することもでき、ユーザーはプログラムを使って翻訳をアップロードできます。

ダッシュボードでキャンペーンを作成する際、{{content_blocks.${name_of_content_block}}} タグを使用してコンテンツブロックを参照できます。これらのブロックは、オプション1に示すように、各言語の条件ロジック内にすべての翻訳を格納することもできるし、各言語ごとに独立したブロックを使用することもできる。

コンテンツブロックは、翻訳が必要なコンテンツをコンテンツブロック内に格納し、取得、翻訳、更新するための翻訳管理プロセスとしても利用できます。

  1. 「翻訳要」というタグが付いたコンテンツブロックをダッシュボードに手動で作成します。
  2. サービスが /content_blocks/list エンドポイントを使用してすべてのコンテンツブロックを夜間に取得します。
  3. サービスが /content_blocks/info エンドポイントを通じて各コンテンツブロックの詳細を取得し、どのブロックが翻訳対象としてタグ付けされているかを確認します。
  4. 翻訳サービスは、すべての「翻訳要」コンテンツブロックの本文を翻訳します。
  5. サービスは /content_block/update エンドポイントにアクセスして翻訳されたコンテンツを更新し、タグを「翻訳完了」に更新します。

オプション 3: カタログ

カタログを使用すると、Liquid のカスタム属性やカスタムイベントプロパティと同様に、インポートされた JSON オブジェクトのデータに API や CSV ファイルを介してアクセスし、メッセージを充実させることができます。以下に例を示します。

次の 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 コンテキスト language 本文
1 1 en Hey
2 1 エス Hola
3 1 pt Oi
4 1 de Hallo
5 2 en Hey
6 2 エス Hola
7 2 pt Oi
8 2 de Hallo
9 3 en Hey
10 3 エス Hola
11 3 pt Oi
12 3 de Hallo

これらのカタログアイテムは、以下に示すようにパーソナライゼーションを使用して参照したり、セレクションを使用してデータのグループを作成したりできます。

1
2
3
4
{% catalog_items translations 1 %}
{{items[0].body}} 

//returns “Hey”

オプション 4: ロケールを追加する

メッセージングのロケールを追加して使用することで、1 つのメールキャンペーンやキャンバス内で異なる言語のユーザーをターゲットにすることができます。

オプション 5: ローカライゼーションパートナー

TransifexCrowdin など、多くの Braze パートナーがローカライゼーションソリューションを提供しています。通常、ユーザーは社内チームや翻訳業者と一緒にプラットフォームを使用します。これらの翻訳はそこにアップロードされ、REST API 経由でアクセスできるようになります。これらのサービスでは多くの場合、コネクテッドコンテンツを活用して、ユーザーが API 経由で翻訳を取得できるようにしています。

例えば、次のコネクテッドコンテンツの呼び出しでは、Transifex と Crowdin を呼び出して翻訳を取得し、{{${language}}} を利用して特定のユーザー用に正しい翻訳を特定します。その後、この翻訳が JSON ブロックの「文字列」に保存され、参照されます。

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}}

オプション 6: 公開 Google スプレッドシートでの翻訳

別の翻訳方法として、Google スプレッドシートに翻訳を保管する方法があります。多くの場合、翻訳会社と提携して翻訳を行います。ここに保存されている翻訳は、コネクテッドコンテンツを使用してクエリできます。その後、ユーザーの言語に基づいて、送信時に関連性の高い翻訳がキャンペーンの本文に取り込まれます。

オプション7:Google スプレッドシートを SheetDB 経由で JSON API に変換

このオプションは、Google スプレッドシートを、コネクテッドコンテンツ経由でクエリされる JSON オブジェクトに変換する代替方法を提供します。スプレッドシートを SheetDB 経由でJSON API に変換することで、API 呼び出しの頻度に応じて複数のサブスクリプションティアから選択できます。

スプレッドシートの構造はオプション 4 の手順と同じですが、SheetDB にはオブジェクトをクエリするための追加のフィルターも用意されています。

Liquid とコネクテッドブロックの依存関係が少ない SheetDB を実装したいユーザーは、大きな条件付きブロックを構築するよりも、GET リクエスト呼び出しに SheetDB の検索メソッドを実装して {{${language}}} Liquid タグに基づいてJSON オブジェクトをフィルタリングして 1 つの言語の結果を自動的に返すことができます。

ステップ 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 の言語タグを使用する

次に、コネクテッドコンテンツの呼び出しに Liquid タグ {{${language}}} を実装します。ここで 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 は制限付きの無料アカウントと複数の有料オプションがあり、キャンペーン戦略に基づいて検討する必要があります。
  • コネクテッドコンテンツ呼び出しはキャッシュできます。API 呼び出しの予測ケイデンスを測定し、検索メソッドを使用する代わりにメインの SheetDB エンドポイントを呼び出す別の方法を検討することをお勧めします。
「このページはどの程度役に立ちましたか?」
New Stuff!