> For the complete documentation index, see [llms.txt](https://app.developers.karte.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://app.developers.karte.io/karte-for-app-best-practices/best-practices-for-sending-view-events.md).

# KARTE for Appでのviewイベント送信のベストプラクティス

## KARTE for Appでのviewイベント送信の目的

KARTE for Appでは、エンドユーザーがどの画面を閲覧しているかについてviewイベントとして送信することを期待しています。

このviewイベントは、SDKやKARTE上で以下の役割を持っています。

* KARTE側にエンドユーザーがどのような画面を見ているかを認識させる
* 認識されたviewイベントをpopup等の接客サービス配信のトリガーとして利用する
* 既に画面上にpopupの接客サービスが表示されている場合に、新たにviewイベントが発生した場合にSDKが画面境界を認識し、popupを非表示化させる

**viewイベントは原則として、すべての画面の描画時に送信してくだたくことを想定しています。** viewイベントの設計等でご不明等や相談事項があれば、担当のカスタマーサクセスまでお問い合わせください。

以降ではviewイベント送信のアンチパターン、FAQ等について取り扱います。

## viewイベント送信のアンチパターン

以下のような形式でviewイベントを送信するように実装した場合、KARTEの運用上で問題が生じる可能性があります。

**他の解析ツールに閲覧情報を送信しているロジックをそのまま流用する**

* 解析ツールの場合は閲覧の計測に応じたpopupの配信を行わないことが多いため、popupの配信トリガーとしての役割を持つKARTEのviewイベントとは役割が異なる場合もあります。そのため他のツールで送信しているロジックを流用した場合には、KARTEが想定する形でエンドユーザーの閲覧行動を認識できない、popupの配信が行えないといった問題が生じる場合もあります。
* viewイベントの目的に合わせて、適切なviewイベント送信の設計と実装が必要になります。

**SDKが自動認識する画面境界の発生前にviewイベントが送信される**

* SDKが画面境界を認識した際には、画面の切り替わり後にpopupが残存しないよう、表示中のpopupを非表示化する挙動になっています。
* 画面境界の発生前にviewイベントが送信される場合は、popupの表示直後に画面境界が認識され、意図しないタイミングでpopupが非表示化される、もしくは表示自体が阻害される可能性があります。
* 各OSやUIフレームワークに寄って、適切なタイミングでviewイベントが送信されるように実装してください。
  * [iOS(UIKit)でのviewイベント送信の推奨タイミング](https://app.developers.karte.io/karte-for-app-best-practices/pages/mK4RxLcoomKsWbc5pX1m#viewイベントの送信)
  * [Androidでのviewイベント送信の推奨タイミング](https://app.developers.karte.io/karte-for-app-best-practices/pages/YBAyES9yTVLEXDcgZM2v#viewイベントの送信)
* 参考情報
  * [画面の境界を認識する条件(iOS)](/ios-sdk-appendix/concepts-boundary-transition-ios-sdk.md)
  * [画面の境界を認識する条件(Android)](https://app.developers.karte.io/karte-for-app-best-practices/pages/Y5Rfw5snu31TcDZy0UuJ#画面の境界を認識する条件)
  * [ネイティブアプリにおける接客表示制御](https://support.karte.io/post/3JaA3BlXQea59AaPGxD3bb)

**短期間で1つのviewイベント送信に前後して、別のviewイベントが送信される**

* SDKが自動認識する画面境界と同様に、viewイベントの発生にも依存してpopupの非表示化が行われます。
* 実装上の都合で1つの画面上に複数のViewController/Activity等が読み込まれ、それぞれの読み込みに応じて自動でviewイベントが送信されるような実装になっている場合では、配信のトリガーとして扱いたいviewイベントに前後して他のviewイベントが発生し、結果としてviewイベントの発生による画面境界の認識で意図しないタイミングでpopupが非表示化される、もしくは表示自体が阻害される可能性があります。

**アプリ内WebViewの閲覧をSDK経由のviewイベントとして送信する**

* アプリ内WebViewについては、アプリ内WebViewへの計測タグ設置によるviewイベント計測と、SDKのWebView連携機能を利用した計測を推奨します。
* [WebView内の行動をトラッキングする(iOS)](/ios-sdk/webview-ios-sdk.md)
* [WebView内の行動をトラッキングする(Android)](/android-sdk/webview-android-sdk.md)

**スクロール等に応じて動的にviewイベントが送信される**

* スクロールに応じたイベント送信はイベント数が増加しやすく、イベント送信数のリミットに抵触する可能性があります。また同一ページ上でのスクロールの場合、後述のfield値が区別できないという問題も併発する場合があります。
* viewイベントではなく、カスタムイベントとしての送信でもイベント送信数のリミットについては同じものが適用されます。

**viewイベントで送信されるfield値が区別できない**

* viewイベントではview\_name, titleというfieldで**画面をユニークに識別できる文字列**が送信されることを期待していますが、異なる画面で送信されるviewイベントでこれらが重複している場合、KARTE上では画面の違いを識別できません。

## viewイベントの実装不備に伴う問題

viewイベントの設計や実装に不備がある場合には、下記のような問題が生じる可能性があります。

**viewイベントの送信に抜け漏れがある場合**

* 意図したタイミングでpopupの表示/非表示ができない
* 閲覧履歴に応じたターゲティング等を行う場合に、閲覧履歴が存在しない扱いになってしまう

**viewイベントが過剰に送信されていまう場合**

* 意図しないタイミングでpopupが表示されてしまう
* 意図しないタイミングで表示中のpopupが消えてしまう、もしくは表示が阻害されてしまう
* 閲覧履歴に応じたターゲティング等を行う場合に、閲覧履歴が過剰に認識され、閲覧回数等が正常に認識されない
* イベント送信数のリミットに抵触する

## 実装上の理由で、画面境界の認識を回避しにくい場合のワークアラウンド

KARTE for Appではpopup表示制御のオプションとして、画面境界を認識した際に非表示化させない（常に表示する）オプションの指定が可能です。

[ネイティブアプリにおける接客表示制御](https://support.karte.io/post/3JaA3BlXQea59AaPGxD3bb)

このオプションを指定した場合には画面境界を認識してもpopupが非表示化されないため、ユーザーの操作によってpopupを閉じるか、アプリ側でSDKを介してpopupを非表示化させるdismiss()を呼び出さない限りは、popupの表示が継続します。

実装上の理由で、viewイベントの送信タイミングに対して画面境界の認識が回避しにくい場合は、以下のような設定を組み合わせることで対応可能な場合があります。

* popupの表示制御を常に表示し、画面境界の認識時にpopupが表示化されない設定にする
* アプリ側で表示中のpopupを非表示化させたいタイミングで、適宜dismiss()を実行する形で実装する
  * [アプリ内メッセージを非表示にする(iOS)](https://app.developers.karte.io/karte-for-app-best-practices/pages/HovR7VPq6Fhx8QHaj3YM#アプリ内メッセージを非表示にする)
  * [アプリ内メッセージを非表示にする(Android)](https://app.developers.karte.io/karte-for-app-best-practices/pages/KRt8gy8ifbj5tx2sqMdX#アプリ内メッセージを非表示にする)

※あくまでもワークアラウンドの1形態であるため、この方法での回避ができないケースも存在します

## viewイベントの設計について

通常KARTE for Appの契約時の[オンボーディング](/karte-for-app-start-guide.md)で、担当のカスタマーサクセスと施策内容に応じた設計を行います。

設計についてのご不明点や相談、または既存の設計についての見直し等があれば、適宜お問い合わせください。

## FAQ

### ハーフモーダルやOS側のダイアログ等の描画時に、viewイベントを送信する必要がありますか？

viewイベントの役割に則り、以下の観点が必要であれば送信を推奨します。

* ハーフモーダルの描画に合わせて、popupの表示を行いたい
* ハーフモーダルの描画に合わせて、既に表示されているpopupの表示化を行いたい

またこれと合わせて、dismissによるpopupの非表示化や、suppress/unsuppressで特定画面でのpopup表示抑制等も対応可能ですので、合わせてご検討ください。詳細な方法については以下のドキュメントをご確認ください。

* [アプリ内メッセージの表示を制御する(iOS)](/ios-sdk-appendix/appendix-iam-control-ios-sdk.md)
* [アプリ内メッセージの表示を制御する(Android)](/android-sdk-appendix/appendix-iam-control-android-sdk.md)

### viewイベントに合わせて、商品情報等を追加で送信できますか？

viewイベントにはview\_name, title以外にも任意のfieldを追加いただけます。

ただし画面描画のタイミングに対して、追加送信したい情報が非同期で参照される場合には、viewイベントが送信可能になるタイミングが一般的に想定されるviewイベントの送信タイミングよりも遅れることも想定されます。

その場合には、遷移前の画面で表示させていたpopupが意図したタイミングで非表示化できないような可能性もあるため、場合によっては画面描画時にviewイベントを送信し、追加送信したい情報については参照完了時に非同期で別のカスタムイベントを送信するといった方法が望ましい場合もあります。

※OS間で送信順に差異があるような場合は、接客サービスの配信ルール等をOS間で共通化できない等の問題が生じる場合もあります

参考: [ユーザー解析における「強整合性」について](https://support.karte.io/post/l9sqplRlHKO1bpM6fpgyt)

### アプリ内WebViewの計測はできますか？

アプリ内WebViewに計測タグを設置し、適切にWebView連携を実装することで対応可能です。

* [WebView内の行動をトラッキングする(iOS)](/ios-sdk/webview-ios-sdk.md)
* [WebView内の行動をトラッキングする(Android)](/android-sdk/webview-android-sdk.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://app.developers.karte.io/karte-for-app-best-practices/best-practices-for-sending-view-events.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.