この記事では

以下の内容を学びます:

• レポートの第一の防衛線として送ったPlaylistにClient Versionをマークする
• 送ったPlaylistを整理するためのPitch Log Channelを設定する
• レポートのコンテキストを追加するためのPlaylistタグを使う
• その習慣から有用なレポートを作成する
• よくあるピッチ追跡の間違いを避ける

最初から共有ワークフローに追跡機能を組み込む

最もよくあるピッチ追跡の問題は、後から活動を再構成しようとすることです。この記事の習慣は共有と並行して実行されるときに最もうまく機能します - Playlistが送られるたびに、すでに正しくマークされ、ファイリングされ、タグ付けされているように。同時に2つのことが起きていると考えましょう: Playlistを共有し、後でレポート可能な方法でその共有を記録します。

保存しながら送ったPlaylistにClient Versionをマークする

最初で最も重要な習慣は、外部に送るPlaylistを保存するときにClient Versionトグルをオンにすることです。これはPlaylist保存設定で適用され、すべてのピッチレポートの基盤として機能します - 実際に送ったPlaylistを内部のショートリスト、リサーチPlaylist、制作中の作業から分けるフィルターを作ります。

このトグルが一貫して適用されないと、アウトバウンド活動をその他のものと区別する信頼できる方法がなくなり、レポートの解釈がずっと難しくなります。Playlistが送られるたびに、共有する前にオンにしてください。

Pitch Log Channelを設定する

Pitch Logという専用Channelを作り、送ったPlaylistが集まる明確な場所として活用しましょう。その中に月別、会社別、またはピッチングの方法に合った別の構造でフォルダーを追加してください。

多くのチームにとって月別フォルダーが最も簡単な出発点です - 活動が明確なタイムラインで続いていくからです。他のチームはクライアントグループやプロジェクトタイプ別に分けることを好みます。正確な構造よりも一貫性の方が重要です。

大切なのは、送ったPlaylistが意図的な場所に保管されることです - Channelにファイリングされているかどうかに関わらず常に表示されるBrowseの他のすべてのPlaylistと一緒に漂っているのではなく。

一貫した方法で送ったPlaylistを保存する

ピッチングしたPlaylistを保存またはファイリングするときは一貫して行いましょう - Pitch Log Channelに追加し、正しいフォルダーに配置し、適切なPlaylistタグを適用し、実際に外部に送った場合はClient Versionとしてマークしましょう。

シンプルで繰り返せるワークフローが複雑なものよりも通常は優れています。すべてのアウトバウンドクライアントPlaylistは次のパターンに従えます: Playlistを保存し、Client Versionをオンにし、関連するPlaylistタグを追加し、Pitch Logに追加する。

Playlistタグでレポートのコンテキストを追加する

PlaylistタグはPlaylistが置かれている場所を変えずにPlaylist周辺のコンテキストを説明できるため、ピッチ追跡に最も役立つツールの一つです。ピッチ追跡に役立つタグには、会社またはクライアント名、プロジェクト名、メディアタイプ、地域、内部キャンペーン名、部署またはチームが含まれます。

チームが特定のクライアントにピッチングしている場合、すべての関連PlaylistにそのクライアントH名をタグ付けしましょう。作業が広告に関連する場合はAdvertisingタグも追加しましょう。後でそれらのタグにより、そのクライアントやメディアタイプに関連するすべてのPlaylistをはるかに簡単に見ることができます - Playlistが異なるフォルダーにあっても異なる時期に作成されていてもです。

メディアタイプ別に - Film、TV、Advertising、Radio - 一貫してPlaylistをタグ付けすると、レポートがずっと意味のあるものになります。Playlistの長いリストを見るだけでなく、アウトバウンド作業をサポートした機会の種類別にフィルタリングできます - 今四半期に何件の映画ピッチが出たか、特定のアーティストがどれだけ多くのTV関連ピッチングを受けたかといった質問に答えやすくなります。

その習慣からレポートを作成する

DISCOでReportsを開くときは明確な質問から始めましょう - 一つの会社に送ったすべてのPlaylist、過去30日間のすべてのクライアントPlaylist、映画のために送ったすべてのPlaylist、または外部に送った特定のアーティストを含むすべてのPlaylistなど。

最も役立つレポートフィルターのいくつかは、期間、Channel、Playlistタグ、アーティストメタデータ、"Clients lists only"、"include tags in output"です。

‍

一つのクライアントに送ったPlaylistをレポートする - Playlistに会社名をタグ付けし、Client Versionとしてマークしてから、"Clients lists only"をYesに設定してそのPlaylistタグでフィルタリングしてください。

メディアタイプ別の作業をレポートする - メディアタイプタグでフィルタリングし、"Clients lists only"をYesに設定し、出力にタグを含めましょう。

ピッチングされたPlaylistの特定のアーティストをレポートする - アーティストメタデータフィルターを使い、"Clients lists only"と組み合わせ、メディアタイプ、プロジェクト、またはクライアントのコンテキストも確認できるようにタグを含めましょう。

‍

レポートを他の人と共有またはレビューする予定がある場合は、エクスポートしたCSVに常にタグを含めましょう。タグなしではレポートはどんなPlaylistが存在したかを示します。タグがあると、なぜそれらのPlaylistが存在したかを示します - どのクライアント、どのプロジェクト、どのメディアタイプかを。

避けるべきよくある間違い

実際のピッチログを構築する代わりに記憶に頼ることが最も一般的な問題です。外部ピッチングのためにPlaylistを作りながらClient Versionをオンにしない、Pitch Logにファイリングしない、適切にタグ付けしないと、後でレポートがずっと弱くなります。

もう一つの極端はタグ付けしすぎることです - 誰も維持したくないほど複雑な構造を作ること。よりクリーンなアプローチはPitch Log Channel一つ、シンプルなフォルダー構造、管理可能なPlaylistタグセット、Client Versionの一貫した使用です。

まとめ

ピッチ追跡は最初から共有ワークフローの一部であるときに最もうまく機能します。保存しながら外部に送ったすべてのPlaylistにClient Versionをマークしましょう。Pitch Log Channelを使って送ったPlaylistを整理しましょう。Playlistタグを適用してクライアント、プロジェクト、メディアタイプなどのコンテキストを追加しましょう。Reportsを使って時間をかけてその活動をフィルタリングしてレビューしましょう。これらの要素が連携すると、DISCOはチームが何をピッチングしたか、どこに行ったか、後でどのように理解するかの明確な記録になります。