為什麼團隊溝通比您的Martech團隊更重要

營銷團隊溝通與分析

Simo Ahava關於數據質量和通信結構的非典型觀點使整個會議廳煥然一新。 去分析! 會議。 威克斯,獨聯體地區的MarTech負責人歡迎成千上萬的專家參加此次聚會,以分享他們的知識和想法。

OWOX BI團隊 希望您考慮一下Simo Ahava提出的概念,它肯定具有使您的業務增長的潛力。 

數據質量和組織質量

數據的質量取決於進行分析的人員。 通常,我們會將所有數據缺陷歸咎於工具,工作流和數據集。 但這合理嗎?

坦白地說,數據質量直接與我們在組織內部的溝通方式息息相關。 組織的質量決定一切,從數據挖掘,估計和度量的方法開始,再到處理,再到產品和決策的整體質量,到一切都決定了。 

公司及其溝通結構

假設一家公司專門研究一種工具。 該公司的員工非常擅長發現某些問題並為B2B領域解決問題。 一切都很好,毫無疑問,您會認識幾個這樣的公司。

這些公司活動的副作用隱藏在提高數據質量要求的長期過程中。 同時,我們應該記住,為分析數據而創建的工具僅適用於數據,並且與業務問題隔離開來,即使它們是為解決問題而創建的。 

這就是為什麼出現另一種公司的原因。 這些公司專門從事工作流調試。 他們可以在業務流程中發現很多問題,將它們放在白板上,然後告訴高管:

在這裡,在這里和那裡! 應用這種新的業務策略,您會沒事的!

但這聽起來真是難以置信。 不基於對工具理解的建議的效率令人懷疑。 而且那些諮詢公司往往不理解為什麼會出現此類問題,為什麼每一天都會帶來新的複雜性和錯誤,以及哪些工具設置不正確。

因此,這些公司單獨使用的作用是有限的。 

有些公司具有業務專業知識和工具知識。 在這些公司中,每個人都痴迷於僱用具有高素質的人才,對自己的技能和知識有把握的專家。 涼。 但是通常,這些公司並非旨在解決團隊內部的溝通問題,他們通常認為這並不重要。 因此,隨著新問題的出現​​,女巫的狩獵開始了-這是誰的錯? BI專家可能會混淆流程嗎? 不,程序員沒有閱讀技術說明。 但總而言之,真正的問題是團隊無法清楚地思考問題以解決問題。 

這向我們表明,即使在一家充滿了優秀專家的公司中,如果組織不成立,一切都會付出不必要的努力。 成熟 足夠。 在大多數公司中,人們要考慮的最後一件事是,必須成年並承擔責任,尤其是在危機中。

即使是我即將上幼兒園的兩歲孩子,也比我與之合作的一些組織成熟得多。

您不能僅通過僱用大量的專家來創建高效的公司,因為他們全都被某個小組或部門吸收。 因此,管理人員繼續聘請專家,但沒有任何變化,因為工作流的結構和邏輯完全沒有變化。

如果您不做任何事情來在這些小組和部門內外建立溝通渠道,那麼您的所有努力將毫無意義。 因此,溝通策略和成熟度是Ahava的重點。

康韋定律適用於分析公司

有意義的數據-康韋定律

五十年前,一個名叫梅爾文·康威(Melvin Conway)的偉大程序員提出了一個建議,後來被人們廣泛稱為康威定律: 

設計系統的組織。 。 。 受約束產生的設計是這些組織的溝通結構的副本。

梅爾文·康威(Melvin Conway),康威定律

當一台計算機完美地適合一間房間時,這些想法就出現了! 想像一下:在這裡,我們有一個團隊在一台計算機上工作,而在這裡我們有另一個團隊在另一台計算機上工作。 在現實生活中,康威定律意味著這些團隊之間出現的所有溝通缺陷都將反映在他們所開發程序的結構和功能中。 

作者註:

這個理論已經在開發世界中進行了數百次測試,並進行了很多討論。 Conway定律的最確定定義是2000年代初期最具影響力的程序員之一Pieter Hintjens提出的,他說:“如果您是一個糟糕的組織,您將製作糟糕的軟件。” (阿姆達爾·齊普夫:人的十大定律)

很容易看出該法在營銷和分析領域的運作方式。 在這個世界上,公司正在處理從不同來源收集的大量數據。 我們都可以同意數據本身是公平的。 但是,如果您仔細檢查數據集,則會發現收集該數據的組織的所有缺陷:

  • 缺少工程師無法解決的價值觀念 
  • 格式錯誤,沒有人注意,沒有人討論小數位數
  • 在沒有人知道傳輸格式(批處理或流)以及誰必須接收數據的情況下,通信延遲

這就是為什麼數據交換系統會完全披露我們的缺陷。

數據質量是工具專家,工作流專家,管理人員以及所有這些人員之間的溝通的成就。

多學科團隊的最佳和最差的交流結構

MarTech或營銷分析公司中的典型項目團隊由商業智能(BI)專家,數據科學家,設計師,營銷人員,分析師和程序員(任意組合)組成。

但是在不了解交流重要性的團隊中會發生什麼呢? 讓我們來看看。 程序員將長時間努力地編寫代碼,而團隊的另一部分將只是等待他們通過指揮棒。 最後,將發布beta版,所有人都會抱怨為什麼花了這麼長時間。 當第一個缺陷出現時,每個人都會開始尋找別人的責任,而不是尋找避免使他們陷入困境的方法。 

如果我們更深入地了解,我們會發現對共同目標的理解不正確(或根本不正確)。 在這種情況下,我們會得到損壞或有缺陷的產品。 

鼓勵多學科團隊

這種情況的最壞特徵:

  • 參與不足
  • 參與不足
  • 缺乏合作
  • 缺乏信任

我們該如何解決? 從字面上看是通過讓人說話。 

鼓勵多學科團隊

讓我們聚集所有人,設置討論主題,並安排每週會議:與BI進行營銷,與設計師和數據專家進行程序員的營銷。 然後,我們希望人們談論這個項目。 但這還不夠,因為團隊成員仍不在談論整個項目,也沒有在與整個團隊交談。 召開數十次會議很容易下雪,沒有出路,沒有時間去做。 會議後發送的這些消息將浪費其餘時間,並且使您對下一步的工作有所了解。 

這就是為什麼會議只是第一步。 我們仍然有一些問題:

  • 溝通不暢
  • 缺乏共同目標
  • 參與不足

有時,人們嘗試將有關該項目的重要信息傳遞給同事。 但是,謠言機器沒有傳遞消息,而是為他們做一切。 當人們不知道如何在適當的環境中正確地分享他們的想法和想法時,信息將在到達接收者的途中丟失。 

這些是公司在溝通問題中苦苦掙扎的症狀。 它開始通過會議治愈他們。 但是我們總是有另一個解決方案。

帶領所有人就該項目進行溝通。 

團隊中的多學科交流

此方法的最佳功能:

  • 透明度
  • 參與
  • 知識和技能交流
  • 不間斷教育

這是一個非常複雜的結構,很難創建。 您可能知道採用這種方法的一些框架:敏捷,精益,Scrum。 不管你叫什麼名字,都不要緊。 所有這些都是建立在“同時使所有東西在一起”的原則上的。 所有這些日曆,任務隊列,演示演示和站立會議都是為了使人們經常並一起談論該項目。

這就是為什麼我非常喜歡敏捷的原因,因為它包括溝通的重要性,這是項目生存的先決條件。

如果您認為自己是不喜歡敏捷的分析師,請換一種方式來看待它:它可以幫助您顯示工作結果–所有處理過的數據,出色的儀表板,數據集–可以幫助人們感謝您的努力。 但是,要做到這一點,您必須與您的同事見面並在圓桌會議上與他們交談。

下一步是什麼? 每個人都開始談論這個項目。 現在我們有 證明質量 該項目。 為此,公司通常會聘請具有最高專業資格的顧問。 

好的顧問(我可以告訴你,因為我是顧問)的主要標準是,不斷減少他對該項目的參與。

顧問不能僅僅為公司提供一些小秘密,因為這不會使公司成熟和自我維持。 如果您的公司離不開顧問,那麼您應該考慮所收到服務的質量。 

順便說一句,顧問不應該為您提供報告或幫助。 為此,您有內部同事。

僱用營銷人員進行教育,而非委派

聘請顧問的主要目的是教育,確定結構和流程並促進溝通。 顧問的角色不是每月報告,而是將他或她自己植入項目中並完全參與團隊的日常工作。

一個好的 戰略營銷顧問 填補了項目參與者知識和理解上的空白。 但是他或她可能永遠不會為某人做這項工作。 有一天,沒有顧問,每個人都將工作得很好。 

有效溝通的結果是沒有女巫狩獵和指責。 在開始任務之前,人們與其他團隊成員分享他們的疑問和問題。 因此,大多數問題在工作開始之前就已解決。 

讓我們看看所有這些因素如何影響營銷分析工作中最複雜的部分:定義數據流和合併數據。

通信結構如何在數據傳輸和處理中反映出來?

假設我們有三個來源為我們提供以下數據:流量數據,電子商務產品數據/來自忠誠度計劃的購買數據以及移動分析數據。 我們將一個接一個地進行數據處理階段,從將所有數據流式傳輸到Google Cloud到發送所有內容以進行可視化 Google Data Studio 在...的幫助下 谷歌大查詢

根據我們的示例,人們應該問什麼問題以確保在數據處理的每個階段都能進行清晰的溝通?

  • 數據收集階段。 如果我們忘記測量重要的事情,我們將無法及時返回並重新測量它。 事先要考慮的事情:
    • 如果我們不知道如何命名最重要的參數和變量,該如何處理所有混亂情況?
    • 如何標記事件?
    • 所選數據流的唯一標識符是什麼?
    • 我們將如何照顧安全和隱私? 
    • 在數據收集受到限制的情況下,我們將如何收集數據?
  • 將數據流合併到流中。 考慮以下:
    • ETL的主要原則:是批量還是流類型的數據傳輸? 
    • 我們如何標記流和批處理數據傳輸的結合? 
    • 我們如何在相同的數據模式中調整它們而不會造成損失和錯誤?
    • 時間和時間問題:我們將如何檢查時間戳? 
    • 我們如何知道數據更新和充實是否在時間戳內正常工作?
    • 我們將如何驗證匹配? 無效點擊會怎樣?

  • 數據匯聚階段。 注意事項:
    • ETL流程的特殊設置:我們必須處理無效數據嗎?
      修補還是刪除? 
    • 我們可以從中獲利嗎? 
    • 它將如何影響整個數據集的質量?

所有這些階段的第一個原則是錯誤相互疊加並相互繼承。 在第一個階段收集的有缺陷的數據將使您的頭部在隨後的所有階段中稍有燃燒。 第二個原則是您應該選擇點來保證數據質量。 因為在聚合階段,所有數據都將混合在一起,因此您將無法影響混合數據的質量。 這對於機器學習項目非常重要,因為在這種情況下,數據質量會影響機器學習結果的質量。 使用低質量的數據無法獲得好的結果。

  • 可視化
    這是首席執行官階段。 當首席執行官查看儀表板上的數字並說:“好吧,今年我們獲得了很多利潤,甚至比以前更多,您可能已經聽說過這種情況,但是為什麼所有財務參數都位於紅色區域?” 現在,尋找錯誤為時已晚,因為錯誤早就應該被發現。

一切都基於交流。 並討論話題。 這是準備Yandex流時應討論的示例:

Marketing BI:Snowplow,Google Analytics(分析),Yandex

您只會與整個團隊一起找到大多數這些問題的答案。 因為當某人基於猜測或個人意見做出決定而不與他人測試該想法時,就會出現錯誤。

即使在最簡單的地方,處處都有復雜性。

這是另一個示例:在跟踪產品卡的印象得分時,分析師會注意到一個錯誤。 在匹配數據中,所有橫幅和產品卡片的所有展示都在頁面加載後立即發送。 但是我們不能確定用戶是否真的看過頁面上的所有內容。 分析師來團隊以詳細告知他們。

BI說我們不能離開那樣的情況。

如果我們甚至不能確定是否顯示了產品,我們如何計算CPM? 圖片的合格點擊率是多少?

營銷人員回答:

大家好,我們可以創建一個顯示最佳點擊率的報告,並對照其他地方的類似廣告素材橫幅或照片進行驗證。

然後開發人員會說:

是的,我們可以藉助滾動跟踪和主題可見性檢查的新集成來解決此問題。

最後,UI / UX設計人員說:

是的最後,我們可以選擇是否需要懶惰滾動或永恆滾動或分頁!

這是這個小型團隊執行的步驟:

  1. 定義問題
  2. 提出問題的業務後果
  3. 衡量變化的影響
  4. 提出技術決定
  5. 發現了不小的利潤

為了解決此問題,他們應該檢查所有系統的數據收集。 數據模式的一部分中的部分解決方案無法解決業務問題。

對齊調整設計

這就是我們必須共同努力的原因。 每天都必須負責任地收集數據,這是很難的工作。 和 數據質量必須通過 僱用合適的人,購買合適的工具,並投入金錢,時間和精力來構建有效的溝通結構,這對於組織的成功至關重要。

你覺得呢?

本網站使用Akismet來減少垃圾郵件。 了解您的評論如何處理.