The Inside of Mail.Ru Technology Forum 2011：イベント管理のハイテク

Mail.Ru Group 2011テクノロジーフォーラムは終了しました。今こそ、イベント自体の「裏返し」について話すときです。 これは多くの人にとって興味深く、役に立つと思います。



このブログの対象者は主にIT担当者であるため、まずフォーラムの組織について、自分に近い技術とアプローチに偏りがあることをお伝えします。



次のトピックについて説明します。

• 訪問者に関するすべて ：計算、統計、推奨事項、結論、投票率の推定方法、キューとの戦い方、トラフィックの変換など
• ビデオ放送に関するすべて ：ソフトウェア、ハードウェア、レポート後1時間以内に最初のビデオを公開する方法、問題点、解決方法など
• オンラインで写真を撮ることについてのすべて ：リアルタイムの写真公開システムの仕組み。
• Twitter / SMS /ウェブサイト経由で質問を受け取る
• リアルタイム速記：ソフトウェア、問題、解決策 。

訪問者について

登録時に収集するものは何ですか？ サイトを設計するときは、登録段階で収集される一連のデータ、必須フィールド、入力するデータの形式を慎重に検討する必要があります。 その後、変更するには遅すぎます。 特に、データを直接入力することに加えて、登録の日付と時刻を保存する必要があります-これにより、登録と変換のペースを評価できます。 データベースがいっぱいになると、電子メールアドレス、電話、場合によっては役職を持つ会社を整理し、これを可能な限り自動化に移行する必要があります。 たとえば、登録データベースの約90％に正しい電話番号と電子メールがあります。 しかし、このトピックにはもう1つアドバイスがあります。



トラフィックのソース 。 登録時にトラフィックソースを収集することを強くお勧めします。 これは、わずかに異なるアドレス（たとえばtechforum.mail.ru/?roem ）を異なるサイトに配布し、このアドレスからアクセスしたときに、リファラーとこのパラメーターがセッションに保存され、登録するときにサイトを構成することで自動的に実行できますこのデータは、ユーザーが入力したユーザーデータと共に保存されました。 最悪のオプションは、リファラー、つまりサイトへのリンクがあったページのアドレスのみを分析することです。



投票率を評価する方法は？ 。 登録された1283人のうち700人以上がフォーラムに参加しました。 インフォスペースの収容人数は約700人です。 さらに来るとき、息をするものは何もありません、そして、昼食時とホールで不快なときめきが作成されます。 さて、安全にプレイするのが悪い理由は誰にでも明らかであり、その結果、部屋の半分に行くことになります。 適切な番号を取得するために何が行われましたか？



次の3つのオプションがあります。

• 登録済みのサイトへの訪問者のコンバージョン（つまり、トラフィック品質の割合）;
• 招待された人の登録の変換（つまり、質の高い登録の割合）;
• 招待者の実際の来訪者への変換（つまり、実際の出席率）。

最初の数百の登録を蓄積したら、中間データから最初の2つのパラメーターを推定し、それらから将来の希望する日付までに登録の総数を予測することができます。 難易度は最後のパラメーターです。 無料イベントの調査によると、それは50％から70％の範囲です（このような会議に参加した私の同僚によると、昨年のフォーラムのデータによると）。 もちろん、このような範囲の評価を扱うのは簡単ではありませんでした。



また、累積された登録が「標準以下」であり、出席率が実際にはさらに低くなる恐れもありました。 このリスクを最初に取り除く必要がありました。 これが発明されたために...



登録された最初の1000人の電話調査 。 呼び出しには数時間しかかかりませんでした。 1日の終わりには、次のデータを受け取りました。







コールセンターを介して電話をかけると、具体的な番号が与えられたようです。 登録された人の77％は、来週の水曜日に時間を見つけてドライブするだろうと確信していました。 しかし、それでも、これはベースの定性的特性のほうが多いです。 オペレーターが満足してさよならを言うために何かを言うだけの人もいれば、本当に疑う人もいますが、コールセンターと疑いを共有する人はいませんか？ 一般的に、いくつかの問題を取り除き、他の問題を提起するオリエンテーションを受けました。 たとえば、これらのデータにより、状況について考えさせられました。 それらはすべてどのように適合しますか？ フリーマーケットを防ぐ方法 みんなが十分な昼食を食べられるように？」 その結果、金曜日1200に登録を停止し、配布資料と昼食を調整することにしました。



また、会議に絶対に参加しない人の正確な評価も受け取りました。 そのうちの一人が私たちのところに来ました。 しかし、拒否した人の数を理解することで、登録終了後、新しい人の数からほぼ100を集め、同時に名刺やバッジなどの個々の配布資料を節約することができました。



変換 上記の3つの変換オプションに戻りましょう。 必要な数の登録を獲得し、時間通りに登録を完了するために必要な広告の量を評価するには、サイト訪問者の登録、登録済みから招待、招待への変換-実際に到着した人への変換を理解する必要があります。



私は次の数字を入手しました（2年目はほぼ安定しています）：

• サイトにアクセスしたユーザーの登録済みへの変換（平均） -10％
• 登録済みから招待済みへの変換-95％
• 招待された人を本物の人に変える-51％

ご覧のとおり、51％は77％とは異なり、電話調査を行っています。 そして、これは非常に正常です。拒否した人はほとんど正確に来ず、同意した人はある程度の確率でしか来ないからです。 この確率は66％でした。 また、電話が来るかどうか疑っている人もいました。 投票率は11％でした。



「結局、全員が午前中にフォーラムに来るわけではないのですか？」という質問をするのは理にかなっています。 誰か夕食に来ますか、夕方に誰か？ そして、最終的には、最大1,000人がクラッシュすることなくフォーラムを通過できます！」 イベント前にこの質問に答えることはできませんでした。 来年は楽になります。 なんで？



午前中はいくらですか？ 午前、午後、午後の何人の人々が無料のイベントに来るかについて興味深い数字を得ました。 これを行うために、フォーラムに来たさまざまな色のマーカーを強調表示するようにレジストラに依頼しました。 11時と13時に、彼らは組織的に色を変えました。 結果を分析した後、私はこのアライメントを得ました：







もちろん、朝にバルクが来ることは明らかでした。 しかし、この図はすでに有用です-「レジストラ」のスタッフの作業負荷を計算するために。



登録のための長いキューの回避朝の「フリーマーケット」を回避するために、レジストラのテーブルに人々を均等に分散させる必要がありました。 これを行うために、5、6、7、8、9、10のテーブルと各テーブルのバッジの数でオプションをモデル化しました。 「最初の文字」の統計は次のとおりです







Kでは、Tより4倍多くの人が必要であることがわかります。文字をグループ化することは、順番に必要であり、恐ろしいことではありません（まれなゲストは、最初のテーブルで低頻度文字が収集される登録を理解します）。



8つの「テーブル」については、次のようになります（垂直方向-テーブル上のバッジの数）：







テーブルを1つ増やすと、すべてがほぼ整列します。







分布はほぼ均一であることが判明しましたが、1つのテーブルでは何も実行できませんが、非常に頻度の高い文字で囲まれています。



フォーラム参加者間のビジネスコミュニケーションを改善する方法 。 参加者ごとに、10枚の名刺が印刷されました。 アイデアは表面にあるように思えます。結局のところ、人々はセミナー、展示会、会議に参加してコミュニケーションを取り、名刺は連絡先を交換する最も便利な方法です。 多くの場合、システム管理者、プログラマー、テスターに​​はまったくそれらがありません。 おそらくフォーラムで最も有用なrazdatka。



私が名刺を使って考え、考えを練ったとき、印刷会社は次々に拒否しました。 「名刺の別のフィールド用」の追加価格で誰かが私を楽しませてくれました。 誰かがすべての1200奇数セットを手動でタイプセットすることを引き受けました。 その結果、請負業者が見つかりましたが、彼は締め切りを少し失望させ、会議の開始直前にこれらの名刺を整理しました。



技術的には、レイアウトを準備し、さまざまな個別セットを短時間で簡単に印刷できます。 これは、「マージ」機能を使用して実行できます。 Microsoft Word、Corel Draw、InDesign、および他の多くのドキュメント準備システムにあります。 これは次のように機能します。フィールドはレイアウトに配置され、値を持つテーブルがプログラムにプッシュされます。出力では、フィールドにすでに入力された複数ページのドキュメントがあります。 確かに、この関数は、DTPソフトウェアの製造元によってサポートされていないため、切り株デッキで機能するすべての場所で、あまり一般的ではありません。 しかし、少し整理すると、プログラムがどのボリュームで「屋根を吹かない」かを理解すれば、かなりまともな結果が出ます。 私たちのおかげで、私たちの印刷会社は今それを行うことができます。



登録プロセス中に、ポジションと利益に関するデータを収集しました。 これは、このトピックまたはそのトピックが私たちの聴衆にとって興味深いかどうかを理解し、リスナーとして私たちにとって興味深い人、そして何らかの理由で登録の途中で欠けていた人を引き付けるために広告を調整するために必要でした。 その結果、次のような状況になりました。







最後に、別の興味深い統計を提供できます。 フォーラムへの訪問者の「女性のシェア」は少なくとも13％でした。 これはフォーラムのかなり高い指標であり、プレゼンテーションではコードが表示され、会場のいたるところにシステム管理者や筋金入りのプログラマーの俗語が表示されます。



したがって、会議の結果として、来年の投票率をより正確に予測し、最も興味深いスピーカーを選択できるようにする多くのデータを受け取りました。



「技術的な詳細」



認可の方法 。 人は登録できるので、データを変更したり、ニュースレターの購読を解除したり、フォーラムへの参加を拒否したりする方法が必要です。 ここでログインとパスワードによる認証を明らかに冗長にしないために、この非常にまれな状況に対して、電子メールによる認証が行われました：ユーザーは、メールボックスの手紙から送信された「秘密」アドレスに行く必要があります。このアドレスの有効期間はわずか数十分です。 住所から編集フォームに移動し、ボックスの所有者のみが手紙を読むことができます。 2つまたは3つがこれを利用しました。 このソリューションは、インターフェースをオーバーロードせず、必要なサービスを提供したため、非常に成功したことが判明しました。

写真

リアルタイムでの写真のレイアウト 。 Mail.ru Group 2011テクノロジーフォーラムで完全に実装されたアイデアを簡単に説明すると、撮影からネットワークに写真が届き、ロビーの大画面で数秒が経過するまでです。



私たちのビデオパートナーであるEspleyは、このアイデアの実装に大いに役立ちました。



システムは次のように機能しました。撮影直後のカメラは写真をローカルサーバーに投げ捨て、そこから写真ファイルはすぐにテクニカルFTPサーバーに送られました。 そこで、サーバー上で、PhotofeedがRSS形式でアップロードされました。これは、Photosディレクトリのすべての新しいファイルを反映しています。 このRSSは、大画面で写真を表示するシステムと、Photos @ Mail.ruサービスにファイルをアップロードするシステムの両方で使用されます。 最後の2つのシステムは、写真のコピーをローカルに保存しますが、より小さなバージョンです。



もちろん、可能であれば、写真家は失敗したショットを撮らないことが求められますが、フォーラムのフォトギャラリーからわかるように、2人のEspley写真家が一度にこれを簡単に行うことができます。



下の写真の「サムスン」には、「1分前」と記されているように、撮影した写真が表示されます。 その左側には、前の写真の端があります。 新しいものが到着するとすぐに、これらはすぐに彼女に取って代わり、左に移動します。 そして背景には、最初のホールからのビデオ放送があります。







写真はフォーラムの開始直後に表示され始め、平均して毎分表示されました。当日は約700枚の写真を受け取りました。 日中は何百人もの人々がフォトギャラリーに行きました。

ビデオおよびビデオ録画

イベントのビデオ録画がこんなに遅くサイトに表示されるのはなぜだろうといつも思っていました。 ほとんどの場合、プレゼンテーションとビデオのレイアウトの遅延は、1週間半（Highload ++、プレゼンテーション）から3〜4週間（Yandex YaC会議、ビデオ、プレゼンテーション）までです。 特別なイベントの多くは、ビデオをまったくアップロードしません（RIF + CIB、RIW）。



同じ日にビデオレポートを公開する方法を学びたかった。 結局のところ、すべてのレポートに出席することは不可能であり、3週間後には誰もがすでに会議を忘れていることは明らかであり、イベントに関する情報をネットワークに公開するには遅すぎます。



さまざまな企業との一連の会議の後、 ESPLEYを選択しました 。 この会社は、当初から非常に有能にこの問題に取り組み、非標準であるが非常に効果的なソリューションを提案し、最終的には私たちの側から最も大胆な勧告を獲得しました。 さらに、それらとの協力の2つの分野-速記（下記参照）と写真（上記参照）が見つかりました。



それで、私たちは何になりましたか？

• 4つのプロHDカメラが2つの部屋からレポートを撮影し、同時にそれらをフィルムに高品質で記録しました。
• 2つのラップトップがプレゼンテーションスライドを大画面だけでなく、ビデオをインターネットにブロードキャストする機器でもブロードキャストします。
• オンラインブロードキャストの2人のディレクターが、カメラからのビデオと信号のプレゼンテーションラップトップを組み合わせて、ホールごとに1つの2つのビデオストリームにしました。
• その結果、4つのストリームがサーバーに送られ、ビデオがインターネット上で配信されました。2つはライブ画像で、2つはスライドのみです。 このサイトでは、両方のビデオを同時に見ることができました。
• ホールの1つからのビデオがロビーの大画面で放送されました。
• レポートの後、ビデオは自動的に目的の形式に変換され、特に速記者が使用するリポジトリにコピーされました。
• 新しいビデオがリポジトリに表示されると、My World @ Mail.Ruに転送され、そこから埋め込みメカニズムを介して公式Webサイトのレポートページに転送されました。 会議後、ビデオ放送セクションはビデオ録画セクションに変わり、1ページのすべてのビデオとプレゼンテーションが収集されました。

「分散」サーバーとして、Wowza Media Server 3ソフトウェア（http://wowza.com）が使用されました。 サーバーは、2 Gbチャネル（200 Mbpsで十分でしたが）、2 x Xeon E5520、8 Gb RAMでサイトにインストールされました。 Wowzaのセットアップは非常に簡単で、文字通り「箱から出して」必要なことを行います。 一連のテストの後、最終的にこのソリューションを信じ、最終的には完全に機能しました。 音に問題がありました。すべての機器、同期機器、およびサイト機器を同時にオンにすると、静かな「スプリアス」ノイズが発生しましたが、完全に取り除くことはできませんでした。 ただし、「インフラスペース」には電子機器が「詰め込まれている」だけで、アクセスポイントは40個以上あります。 しかし、次回は、より徹底的なテストと機器の配置によって問題を克服する必要があります。



1日後、モバイルデバイス用の形式に変換されたビデオを利用できるようにしました。 電話で投げて、地下鉄で見たり聞いたりできます。



その結果、少なくとも600人がオンラインブロードキャストを視聴しました。

「質問をする」

報告を聞いた人の質問は、最後にスピーチの「道に沿って」ほど発生しないという仮定がありました。 誰かがそれらをノートに書きますが、結局のところ、幸運な人は3つか4人だけが何かを尋ねる機会を持っています。 事前にサイトにいる間に多くの質問をしたいと思います。 スピーカー自身にとっても、これは便利に見えました。 彼らはパフォーマンスの前に、そしてパフォーマンス中にさえ質問を見るように見えました。



しかし、聴衆から質問を受け取る方法は？ メモ付きの古い実績のある方法があります。 彼は匿名でシンプルです。 しかし、「技術」ではなく、もっと面白いものが欲しかった。 その結果、サイトからだけでなく、TwitterやSMSからも質問を受け入れるという、かなり「つまらない」アイデアを試しました。 たとえば、誰もが電話、ツイッターを持っています-存在するもののほぼ3分の1。



システムは次のように機能しました。

• ハッシュタグ＃ZAL1または＃ZAL2を持つユーザーがメッセージをtwitterに送信すると、間違いなく質問のフィードに入ります。 さらに、質問が行われたレポートは、このツイートの受信時間に応じて選択され、会場と時間を知ることで、質問がどの質問にされたかを確実に知ることができます。 また、データベースには、質問をしたツイートユーザーのニックネームが保存されます。
• メッセージがSMSによって送信された場合、ホールはSMSメッセージ自体から決定されました。ZAL1/ ZAL2 /1/2という単語で開始するように要求しました。 レポート自体は、メッセージが送信された時間によっても識別されました。
• メッセージがWebサイトのフォームから送信された場合、レポートはプレゼンターによって選択されましたが、現在のレポートはデフォルトですでに設定されています。

その結果、「sms」/「twitter」/「サイト上のフォーム」の3つのチャネルすべてから、すべての質問が単一のストリームに収集されました。 現時点では、スピーカーはすべての質問に答え、彼らの答えはサイトに投稿されています。



私たちの小さな欠点は、口頭ではなく質問をする機会そのものを「広告」しなかったことです。 また、口頭での質問については、ギフトiPadの形で非常に深刻な動機付けがあり、質問は主に聴衆から寄せられました。 確かに、賞品を獲得する機会があるため、レポート後の質疑応答は非常に面白く、「活気に満ちた」ものであり、ギフトを残した人だけでなく、他のすべての人も恩恵を受けました。

レポートのステノグラフィー

それは会議で最も大胆かつ実験的なものであり、今日まで誰も聞いていなかった。 長い間、私は、サイト上のテキストがビデオ放送とほぼ同時に表示されるときに、すべてのレポートの写しをリアルタイムで「育て」ました。



もちろん、特に私たちのトピックに関する音声認識はオプションではありません。 自動認識ではなく自動認識に焦点を合わせました。



私がやりたい（そして最終的に成功した）ことは次のとおりです。ビデオストリームは小さなフラグメントに分割され、それぞれが個々の速記者に送信され、速記者はフラグメントを操作し、エディタは既製のテキストを使用します。



このようなソリューションのサプライヤーと数回の会議が開催されました。 残念ながら、技術的な解決策、それから価格、または他の何かのいずれかが、それらのそれぞれで私たちに合っていませんでした。



その結果、開始から1週間もたたないうちに、ESPLEYのビデオと写真のパートナーは、会議の数日前に必要な製品を作成する強みを見つけ、「速記者」を組織しました。



これは、画面の1つのスクリーンショットです。 解読が始まったばかりで、速記者はまだすべて接続していません。 図が示すように、3人の速記者が並行して動作します.1つ目は最初の2つのフラグメントをすでに解読しており、2つ目-2つ目、2つ目、3つ目-ここでは編集者でありエディターでもあります-5つ目のフラグメントを解読します。 1分を解読するには2〜3分かかります。 並列復号化がサポートされているため、システムは簡単に「スケーリング」できます。







これで、概念実証と呼ばれるものを受け取ったことを自慢できるようになりました。この技術とソフトウェアは、原則としてイベントでうまく採用できるという確認です。 しかし、本格的な本格的な運用はまだ行われていません。 今日の結果は、いくつかの解読されたレポートです。 同じ日に公開することを敢えてしませんでした。スライドと写真でテキストを希釈し、少し編集する必要があります。 近い将来、「最初のツバメ」を見せます。 イニシアチブが視聴者によってサポートされている場合、残りのレポートを押します。



アリエフ・ラウフ、

Mail.Ru Group副テクニカルディレクター