ECの注文・クリック情報と成果管理をつなぐ|ASP・成果計測システムの設計・開発支援
ECの注文情報とクリックなどの計測情報を、企業・ブランド別の成果確認へつなぐWebシステムの設計・開発を支援しました。外部ECとの連携方式と、内部で管理する情報・支払い状態の関係を整理した案件です。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| 対象 | EC・成果管理サービス運営事業者 |
| カテゴリ | EC・Webシステム |
| 開発区分 | 受託開発 |
開発の背景
本件では、外部ECの注文情報と、サービス内で持つクリックなどの計測情報をどう扱うかが設計の対象になりました。注文を取得する仕組みを作るだけでは、運営側が企業・ブランド別に成果を確認し、支払いの状態を管理する業務まではつながりません。
UHDは、外部ECとの接続方式と内部で管理する情報の関係を整理し、設計・開発を支援しました。参照元の注文、計測の記録、認める成果、支払いの状態はそれぞれ役割が異なります。取得できたデータをすべて同じ状態として扱わず、どの段階の情報かを明確にすることが必要でした。
注文とクリック情報を成果管理へ
各段階で何を確認するのかを分け、外部から受け取った情報と、担当者が確認する状態の関係を整理しています。
| 領域 | 設計で扱った情報 |
|---|---|
| EC連携 | 注文情報の受け渡しと接続方式 |
| 計測情報管理 | 日付、ブランド、クリック情報 |
| 成果確認 | 注文と計測情報、確認条件 |
| 支払い状態 | 確定、繰越、支払い済みなどの状態 |
例えば月次の確認では、対象ブランドと期間をそろえて情報を確認し、その後の支払い状態を扱います。成果の判定条件と支払い状態は、別の管理事項として整理する設計です。
設計で想定するのは、成果管理の担当者が対象ブランドと期間を選び、注文と計測情報を確認する業務です。取得したデータをそのまま一つの数値にするのではなく、どの企業・ブランドの情報か、どの期間の確認かをそろえる必要があります。
その後、成果の確認条件に沿って対象を整理し、確定・繰越・支払い済みなどの状態を扱います。注文があること、成果確認が済んでいること、支払い済みであることは異なる段階です。
本件では、これらを分けて管理する関係を設計の対象にしました。月次の確認や問い合わせで、どの段階の情報を見ているかを明確にするための整理です。
企業・ブランドごとに記録を確認
外部サービスのAPIには、参照できる情報や利用方法に制約があります。その前提を確認し、内部のクリック情報と注文情報をどこで関連付けるか、管理側にどの情報を持たせるかを検討しました。連携できるという説明だけで終わらせず、成果確認に必要な情報がそろうかを設計の対象にしています。
利用例としては、運営担当者が企業・ブランドと期間を指定し、対象の記録と成果・支払い状態を確認する場面です。本件では、外部ECとの連携方式と、成果・支払いの管理範囲を整理する設計・開発支援を行いました。
特定ECのWebhookだけに依存しない注文連携方式を比較しました。外部サービス側の制限を踏まえ、計測情報を内部DBで管理する方針を整理しています。
外部の注文受信、内部の情報保存、成果確認、支払い状態の更新を分け、どの段階を調べるべきかが分かる関係を重視しました。
企業・ブランド・期間の条件は、成果を確認するための共通の入口になります。企業とブランドの関係を整理することで、どの対象の注文や計測情報を調べるかが分かります。
ブランドごとの情報を扱う場合は、取得元と対象が対応していることが前提です。データの量だけでなく、どのブランドに属する情報かを管理できる関係を設計の対象にしています。
支払い状態もその情報と関連する管理事項です。成果の確認と支払い状態の更新を分け、どこまで確認・処理したかを担当者が把握するための範囲を整理しました。
UHDの担当範囲
要件定義から設計・開発、テスト、リリース対応、追加開発、運用保守までを担当領域とする案件です。本記事では、EC接続と計測・成果・支払い状態を扱う設計支援を紹介しています。
支援の成果
注文連携、クリックなどの情報管理、企業・ブランド管理、支払い状態を扱う設計を整理しました。連携方式の選択と管理範囲の整理を通じて、ECの裏側にある成果管理業務を支援した事例です。
開発のご相談
業務システムの改善や新しいサービスの開発をご検討の際は、現在の業務と実現したいことをお聞かせください。要件整理から開発・運用までご相談いただけます。