機能 · 支払い方法

マッピングされていない方法は 収益としてカウントされません

支払い方法は、ショップ独自の支払い方法名を種類(銀行振込、代金引換、カードオンラインなど)に分類する場所です。受注ステータスと組み合わせることで、その種類が受注が収益を生んだかどうかを決定します。

app.amicited.com/reports/eshop-payment-methods
収益と受注数を表示する支払い方法ページと、方法から種類へのマッピングテーブル
支払い方法
銀行振込、代金引換、カードオンライン
種類
ソースプラットフォーム(例:bizniweb)
タグ付け
分類されるまでゼロ
未マッピングの収益
受注ステータスと共同で
収益の決定方法
収益と受注数は一致しないことのほうが多く、その差が確認すべき理由であることがほとんどです。
組み合わせのもう半分

支払い方法の分類とステータスがともに決定する

受注ステータスは各ステータスの意味を定義し、支払い方法は支払い方法の分類 — 各方法がどの種類の支払いかを扱います。どちらか一方だけで収益が決まることはありません — 両方の組み合わせが許可した場合にのみ、受注がカウントされます。マッピングされていない方法は決してカウントされません。これは未マッピングのステータスがカウントされないのと同じ理由です。まだ到着していないお金をカウントすることは、大きな失敗として声を上げる価値のある唯一のミスだからです。

  • 収益と受注数を並べて表示 — この2つは一致しないことのほうが多く、その差が確認すべき理由であることがほとんどです。
  • ラベルそのものではなく種類 — 銀行振込、代金引換、カードオンラインなど、ショップ独自の支払い方法名からマッピングします。
  • ソースのタグ付き — 例:bizniweb — 複数のプラットフォームから支払いデータを取得しているショップ向け。
  • マッピングなしはゼロ、受注ステータスと同様 — 分類されていない支払い方法は、意図的に収益としてカウントされません。
  • 受注ステータスと連携し、置き換えるものではない — ここで設定する種類と受注ステータスで設定する意味が組み合わさって、各受注が収益を生んだかどうかを判断します。
2つの数値、めったに一致しない

収益と受注数、そしてその差

収益と受注はそれぞれ独自のシェアバーリストとして表示され、値の高い順に並べられます。収益は純収益からアクセントカラー、受注は単純なカウントから緑色で表示されます。各行には、生の方法名、その絶対値、リスト内でのパーセンテージが表示され、バーの長さはそのパーセンテージに一致します。正の値がある場合、最小でも幅1%が確保され、視認性を保ちます。軸、ベースライン、ゼロラインはありません — 幅は純粋にリスト全体に対するシェアであり、合計が正の値でない場合は分割全体が非表示になります。収益シェアが受注シェアよりも大きい方法は、ショップ平均よりも高額な受注を処理していることを示し、その逆は低額な受注を意味します — どちらかの数値単独ではなく、その差が、その方法を開いて種類を確認すべき理由となるのです。

  • 収益 — この方法で支払われた受注に帰属する、レポート通貨での純収益。
  • 受注数 — 収益とは無関係に、その方法が使用された受注の数。
  • 両者の差 — 収益シェアが受注シェアより大きい場合は、高額な方法であり、その受入コストを確認する価値があることを示します。これは自動的な良し悪しの評価ではなく、調査のシグナルです。
  • マッピングとは別 — このミックスは、重複排除されたインポート受注を生の支払い名でグループ化したもので、以下で割り当てる種類によってフィルタリングまたは再グループ化されません。
各方法が持つ情報
収益と受注数を並べて表示
表示内容
はい
一致しないことが多い
確認すべき理由であることが多い
その差
収益と受注数を並べて表示:一致しないことのほうが多く、その差が確認すべき理由であることがほとんどです。
支払い方法
ショップでの方法名 プラットフォームでタグ付け
種類 銀行振込 / 代金引換 / カードオンライン
未マッピング 収益としてカウントされない
マッピングされていない方法は収益として決してカウントされません。まだ到着していないお金をカウントすることは、大きな失敗として声を上げる価値のある唯一のミスだからです。
ショップ独自の名称を分類

bizniwebの支払い文字列をレポートが理解できる種類にマッピング

各行は、ショップのプラットフォームが命名する通りの支払い方法で、ソースがタグ付けされ、プラットフォーム順、次に生の名前順に一覧表示されます。アラートは、まだ「未マッピング」下書きの状態の行数をカウントします。種類(代金引換、銀行振込、カードオンライン、ウォレット、その他)を選択すると、保存ボタンなしですぐに保存されます。ドロップダウンが自動保存し、リクエスト実行中もローカル下書きが表示され続け、「保存中…」または返されたエラーが表示されます。後続のマトリックスでは、代金引換、銀行振込、カードオンライン、ウォレットは「支払済」「処理済」「完了」でカウントされ、「その他」は「支払済」または「完了」でのみカウントされ、「保留中」およびマッピングされていないものは決してカウントされません。キャンセルは常に最初に受注を除外し、受注ステータスでのステータスごとの上書きがその後優先されることがあります。したがって、方法をマッピングしないままにすることは、意図的で保守的なデフォルトです — 分類されるまで、それらの受注は実現収益を生みません。このテーブルは、キャンセルを除いて、支払い方法を収益の種類にマッピングする方法です。

  • ショップでの方法名 — プラットフォーム(例:bizniweb)が送信する正確な支払い方法の文字列。
  • 種類 — 代金引換、銀行振込、カードオンライン、ウォレット、またはその他から選択。変更時に自動保存されるドロップダウン。
  • 未マッピング、収益ゼロ — 受注ステータスと同じフェイルセーフを、組み合わせのもう半分に適用。
  • 編集権限 — オーナー、管理者、編集者がマッピングを変更可能。メンバーとメンテナーは読み取りのみ。ゲストはアクセス不可。
  • ループを完了 — ステータスと支払い方法の種類の組み合わせが、キャンセルを除いて、受注をカウントするかどうかを最終的に決定します。
0 マッピングされていない支払い方法からの収益は、設計上ゼロ まだ到着していないお金をカウントすることは、大きな失敗として声を上げる価値のある唯一のミスです — そのため、種類が割り当てられていない支払い方法は、分類されるまで何も貢献しません。未マッピングの受注ステータスとまったく同じです。 通貨を見る

実際に確定して初めてカウントされる収益

ショップ独自の支払い方法名を種類ごとに分類 — 受注ステータスと組み合わせて、受注が収益を生んだかどうかをともに判断します。

app.amicited.com/reports/eshop-payment-methods
収益と受注数を表示する支払い方法ページと、方法から種類へのマッピングテーブル

実際に収益としてカウントされているものを確認してみませんか?

Free check · 7-day trial · no credit card