この記事では
以下の内容を学びます:
- 送ったPlaylistを整理するためのPitch Log Channelを設定する
- レポートのコンテキストを追加するためのPlaylistタグを使う
- 送ったPlaylistを内部作業と分けるためのClient Versionを使う
- その習慣からH有用なレポートを作成する
- よくあるピッチ追跡の間違いを避ける
Pitch Log Channelから始める
最もシンプルで効果的な習慣の一つは、送ったPlaylist専用のChannelを作ることです。Pitch Logと呼ばれるChannelはチームにアウトバウンド作業を保存する明確な場所を一つ提供します。その中に月別、会社別、またはピッチングの方法に合った別の構造でフォルダを追加しましょう。

多くのチームにとって月別フォルダが最も簡単な出発点です - 活動が明確なタイムラインで続いていくからです。他のチームはクライアントグループやプロジェクトタイプ別に分けることを好みます。正確な構造よりも一貫性の方が重要です。
大切なのは、送ったPlaylistがBrowseの他のすべてのPlaylistと混在せず、意図的な場所に保管されてタグ付けされるかClient Version(Playlist保存設定で)としてマークされることです。Pitch Log Channelは後でレポートをフィルタリングするのも簡単にします。
一貫した方法で送ったPlaylistを保存する
最良のレポートシステムは通常、Reportsエリアを開く前から始まります。ピッチングしたPlaylistを保存またはファイリングするときは一貫して行いましょう - Pitch Log Channelに追加し、正しい月のフォルダに配置し、適切なPlaylistタグを適用し、実際に外部に送った場合はClient Versionとしてマークしましょう。
シンプルで繰り返せるワークフローが複雑なものよりも通常は優れています。例えば、すべてのアウトバウンドクライアントPlaylistは次のパターンに従えます: Playlistを明確に保存し、関連するPlaylistタグを追加し、Pitch Logに追加し、外部に送った場合はClient Versionトグルをオンにする。

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

チームが特定のクライアントにピッチングしている場合、すべての関連PlaylistにそのクライアントH名をタグ付けしましょう。作業が広告に関連する場合はAdvertisingタグも追加しましょう。後でそれらのタグにより、そのクライアントやメディアタイプに関連するすべてのPlaylistをはるかに簡単に見ることができます - Playlistが異なるフォルダにあっても異なる時期に作成されていてもです。
メディアタイプタグでさまざまな種類の作業を追跡する
多くのチームがいくつかの種類の機会にピッチングしています。PlaylistをFilm、TV、Advertising、Radio、または他の関連するメディアタイプで一貫してタグ付けすると、レポートがずっと意味のあるものになります。Playlistの長いリストを見るだけでなく、アウトバウンド作業をサポートした機会の種類別にフィルタリングできます - 今四半期に何件の映画ピッチが出たか、特定のアーティストがどれだけ多くのTV関連ピッチングを受けたかといった質問に答えやすくなります。
Client Versionトグルで送ったPlaylistと内部作業を分ける
DISCOで作成されたすべてのPlaylistが実際に送られるわけではありません。内部のショートリストもあれば、リサーチPlaylistもあれば、最終的なクライアント向け納品物もあります。そのためClient Versionトグルがレポートにとってとても重要なのです。
Playlistを保存するときにClient Versionトグルをオンにして外部送信としてフラグを立てることができます。これによりBrowseのPlaylistに目に見えるClientインジケーターが追加され、一目で区別しやすくなります。このトグルを使って実際に外部に送ったPlaylistを一貫してマークすると、非常に有用なフィルターが生まれます。Client Versionのみにフィルタリングされたレポートは内部準備ではなく真のアウトバウンド活動を反映するため、はるかに正確になります。
いくつかの主要フィルターを中心にレポートワークフローを構築する
DISCOでReportsを開くときは明確な質問から始めましょう - 一つの会社に送ったすべてのPlaylist、過去30日間のすべてのクライアントPlaylist、映画のために送ったすべてのPlaylist、または外部に送った特定のアーティストを含むすべてのPlaylistなど。
最も役立つレポートフィルターのいくつかは、期間、Channel、Playlistタグ、アーティストメタデータ、Clients lists only、include tags in outputです。

一つのクライアントに送ったPlaylistをレポートする
その会社に送ったPlaylistが会社名でタグ付けされてClient Versionトグルでマークされているか確認してから、Reportsを開いてそのPlaylistタグでフィルタリングし、"Clients lists only"をYesに設定し、エクスポートしたレポートにより多くのコンテキストが必要な場合はタグを含めましょう。これは時間をかけて一つの会社の複数の異なる人がPlaylistを受け取る場合に特に役立ちます。
メディアタイプ別の作業をレポートする
メディアタイプタグ - Film、TV、Advertising - でフィルタリングし、"Clients lists only"をYesに設定し、出力にタグを含めましょう。チームがピッチングの時間をどこに使っているかについてのより広い戦略的な質問に答えやすくなります。

ピッチングされたPlaylistの特定のアーティストをレポートする
関連するアーティストメタデータフィルターを使い、"Clients lists only"をYesに設定し、メディアタイプ、プロジェクト、またはクライアントのコンテキストも確認できるようにレポートにタグを含めましょう。これはレパートリー周辺でどんなアウトバウンド活動が起きているかを知りたいアーティスト、マネージャー、レーベルを更新するときに役立ちます。
タグが意味を加えるときはいつでもレポートに含める
レポートはファイル名だけでなくコンテキストを含むときにずっと有用になります。Playlistタグはメディアタイプ、会社、またはプロジェクトを示すことができ、エクスポートしたCSVをずっと解釈しやすくします。タグなしではレポートはどんなPlaylistが存在したかを示します。タグがあると、なぜそれらのPlaylistが存在したかを示し始めます。

避けるべきよくある間違い
実際のピッチログを構築する代わりに記憶に頼ることが最も一般的な問題です。外部ピッチングのためにPlaylistを作りながら一貫してマークしないこと - Pitch Logにファイリングしない、適切にタグ付けしない、Client Versionトグルをオンにしない - はレポートをずっと弱くします。あまりにも多くのエッジケースをタグ付けして誰も維持したくないほど複雑な構造を作ることも避けるべき別の極端です。
よりクリーンなアプローチ: Pitch Log Channel一つ、シンプルなフォルダ構造、管理可能なPlaylistタグセット、Client Versionの一貫した使用、それらの習慣から作られたレポート。
まとめ
ピッチ追跡は後から再構成しようとするものではなく、最初からワークフローの一部であるときに最もうまく機能します。Pitch Log Channelを使って送ったPlaylistを整理し、Playlistタグでクライアント、プロジェクト、メディアタイプなどのコンテキストを追加し、Client Versionトグルで外部送信Playlistを内部作業リストと分け、Reportsで時間をかけてその活動をフィルタリングしてレビューしましょう。これらの要素が連携すると、DISCOはチームが何をピッチングしたか、どこに行ったか、後でどのように理解するかの明確な記録になります。
