シェアで特典をゲット：なぜ提出の半数が却下されるのか、そして却下されないための方法

Share for Perksは難しいプログラムではありませんが、完了率は低いです。開始以来、サプライヤーが提出したすべての提出物のうち、承認されたのは半分弱でした。それはレビュアーが厳しいからではありません。記録された理由を読むと、却下の大部分は2つのうちのどちらかです：開かなかったリンク、または誰にも見えなかった投稿。

どちらも提出前に回避可能であり、このページはそのためのものです。

プラットフォームによって承認率は大きく異なります

以下は承認数の内訳で、単一のアカウントの記録が数字を歪めないよう、提出したサプライヤーごとに分けています。

• X（旧Twitter）：14社のサプライヤーにわたり、承認31件・却下1件。これまでにXのシェアが却下されたサプライヤーは1社だけです。承認を得たいなら、ここが最適です。
• Telegram：18社のサプライヤーにわたり、承認19件・却下29件。そのうち8社はTelegramのシェアが一度も承認されたことがありません。つまりこれは少数の不注意なアカウントの問題ではなく、プラットフォーム自体の特性です。
• Facebook：5社のサプライヤーで、承認3件・却下7件。
• レビューサイト：5社のサプライヤーで、承認2件・却下12件。全ルートの中で最悪の承認率で、ほぼすべてが1つの修正可能なミスによるものです。

Redditは2回使用され、2回とも却下されました。これは率と呼ぶには少なすぎるため、率としては扱いません。

記録された却下のうち2件は管理者のテスト行であり、これらは静かに削除するのではなくこれらの数に含めています。削除すると数字が数ポイント良く見えるからです。

各プラットフォームが要求するリンク形式

51件の却下のうち約28件が「無効なリンク」または「リンクが開かない」という趣旨の理由です。チェッカーはプロフィールページ、招待リンク、シェアのリダイレクトを受け付けません。特定のホストと、いくつかのプラットフォームでは特定のパス形式が必要です。

• Telegram。リンクはt.meホスト上にある必要があります。公開チャンネルまたはグループからのメッセージリンクが有効です。
• X。ホストはx.comまたはtwitter.comである必要があり、かつパスに/status/の後に数値の投稿IDが含まれている必要があります。プロフィールへのリンクは人間が確認する前に拒否されます。
• Discord。ホストはdiscord.comである必要があり、パスは/channels/で始まる必要があります。discord.ggの招待リンクは拒否されます。サーバー招待ではなく、公開チャンネルのメッセージで「メッセージリンクをコピー」を使用してください。
• YouTube。受け付けられており、このプログラムのほとんどの説明では省略されています。youtu.beの短縮リンク、または/watch、/shorts/、/post/パス上のyoutube.comアドレスのいずれかです。つまりコミュニティ投稿も動画と同様にカウントされます。
• Reddit。ホストはreddit.comである必要があり、パスは任意の実在するもので構いません。
• Facebook。ホストはfacebook.comまたはfb.comである必要があり、パスは任意です。

別途、宣伝するページはメインのマーケットプレイスドメイン上のページである必要があります。自分の外部サイト、ミラーサイト、サプライヤーポータルを宣伝すると、レビュアーが関与する前に提出時に拒否されます。

Telegramの問題はリンクではなく、オーディエンスです

Telegramの却下は2つのグループに分かれます。一部は上記のリンク形式の問題です。残りの10件は非常に具体的なことを言っており、レビュアーが基準を正確に教えてくれているので引用する価値があります：チャンネルに自分しかいない、新しく作成された、偽のチャンネルである、そして3件ではXに投稿するよう直接提案されています。

つまりTelegramの基準は「このリンクが公開されているか」ではありません。「実際のオーディエンスがこれを見たか」です。提出用に作成したチャンネルは、そのように認識されます。確立されたチャンネルがない場合、実際に参加している大規模な公開グループに投稿することは機能し、Xに投稿することはさらに機能します。

Facebookの却下も同じ失敗の別の形です：7件のうち5件がレビュアーに投稿が見えなかったと述べています。Facebook自身のプライバシー設定が通常の原因です。提出する前にプライベートウィンドウでリンクを開いてください。サインアウトした状態で見えなければ、レビュアーにも見えません。

レビュー：1つのミスがほぼすべての失敗の原因

レビューはプログラムの中で最も価値の高いアクションであり、ソーシャルシェアのリスト枠の1.5倍の価値があり、毎週のソーシャル枠を消費しません。また、承認率は最悪で、却下のうち3件は同じ言葉で同じことを言っています：レビュアーが求めているのは書いたレビューのURLなのに、レビューサイトのURLを受け取ったというものです。

フローには2つの異なるリンクがあり、混同しやすいです。送られたサイトは証拠ではありません。レビューを公開した後、それを開いてその特定のレビューのアドレスをコピーしてください。それをフィールドに入力するのです。

現在3つのレビュー先が設定されており、これらだけが受け付けられます：Trustpilot、G2、AlternativeToです。レビューは公開され、公開されたままである必要があります。サイトごとに1つのアクティブな提出を保持できるため、このルートからの上限は3つで、1つが決定されるまで変わりません。

各承認が実際に解放するもの

ここがこのプログラムが最も誤って説明される点です。2つの通貨があり、それらは変換されないからです。

リスト枠は両方のルートから得られます。承認されたソーシャルシェアと承認されたレビューのそれぞれが、リスト上限に永続的なボーナスを追加します。レビューの方が大きいです。

機能のアンロックはソーシャルシェアのみから得られます。最初の承認されたソーシャルシェアは、無料のTop Pick申請を1回開きます。これは管理者が承認した後、約1週間、推奨サーフェスに1つの製品を表示します。2回目の承認されたソーシャルシェアは、無料のTelegramチャンネル広告クレジットを1つ付与します。

承認されたレビューはどちらも動かしません。アンロックのラダーにはどの時点でもカウントされません。目標が棚のスペースではなくTop Pickである場合、レビューをいくら完了してもそこには到達できません。

アンロックに労力を費やす前に知っておく価値があること：シェアが承認されると、Top Pick申請自体はほぼ形式的なものです。これまでのTop Pick提出のうち、61件中54件が承認されました。シェアをレビュー通過させることが難しいステップであり、それがアンロックするものは難しくありません。

提出を止める2つの制限

1つは毎週のソーシャル枠で、保留中または承認済みの提出をカウントし、月曜日の00:00 UTCにリセットされ、未使用の枠は繰り越されません。却下された提出は枠を解放するため、却下はその週を失うことを意味しません。レビューはこの枠の外に完全にあります。

もう1つはあまり明白ではなく、複数の投稿を同時に進めている人を捕まえるものです：プログラム全体で、レビュー待ちの提出を最大5件までしか保持できません。それを超えると、何かが決定されるまで提出は拒否されます。毎週の枠がどれだけ残っていてもです。

承認後も投稿を公開したままにする

承認されたシェアは毎週のサイクルで再チェックされます。7日以上チェックされずに承認されたままのものはレビューキューに戻り、その時点で投稿が消えていれば承認は取り消される可能性があります。取り消されたシェアはボーナス枠を連れて戻り、それによってカタログが上限を超える場合、約1週間の猶予期間の後にトリムが実行され、最も新しいアクティブなリストから順にオフになります。

古いリストはそのトリムから保護されるため、損失は最も最近の作業に及びます。それを避ける最も安い方法は、単に投稿を公開したままにすることです。

最短ルート

1. 実際の存在感のあるアカウントからXに投稿し、投稿自体からリンクを取得して/status/と数値IDが含まれるようにします。
2. それを2回行います。承認されたソーシャルシェア2件がアンロックラダーの全体です：1回目でTop Pick、2回目でTelegram広告クレジット。
3. 設定された3つのサイトのいずれかに公開レビューを書き、サイトのアドレスではなくレビューのアドレスを提出します。それが最大のリスト枠の塊です。
4. 何かを提出する前に、サインアウトした状態で自分のリンクを開いてください。ほとんどの却下は、レビュアーがあなたがテストしなかったことを実行できなかったためです。
5. 投稿したすべてを公開したままにし、通知を待つ代わりにページの提出テーブルを確認してください。