惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

WordPress大学
WordPress大学
J
Java Code Geeks
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
腾讯CDC
IT之家
IT之家
罗磊的独立博客
酷 壳 – CoolShell
酷 壳 – CoolShell
U
Unit 42
爱范儿
爱范儿
博客园 - 聂微东
F
Fortinet All Blogs
V
Visual Studio Blog
Blog — PlanetScale
Blog — PlanetScale
G
Google Developers Blog
aimingoo的专栏
aimingoo的专栏
L
LangChain Blog
雷峰网
雷峰网
B
Blog RSS Feed
宝玉的分享
宝玉的分享
T
Tailwind CSS Blog
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
Engineering at Meta
Engineering at Meta
H
Hackread – Cybersecurity News, Data Breaches, AI and More

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
完全基于个人理解的海外产品运营(1)
吴桐 · 2024-04-01 · via 人人都是产品经理

随着互联网的发展,越来越多的岗位逐渐细分,职能也在不断细化。海外产品运营和国内的产品运营有什么不一样?作者基于自己的理解,分享了关于海外产品运营的相关内容,一起来看看吧。

随着时间的推移,互联网行业中各种职业者的职能不断细化,我从事海外产品运营的岗位也有一段时间了,开个坑,分享一下我对产品运营这个岗位的理解。我相信每个人对这个岗位都有不同的理解,由于我是营销出身,更容易进入营销的固有思维模式,而且我目前仅做过面向海外用户的产品运营,所以我能输出的内容也相对的浅显粗鄙,如果大家有更高明的见解,欢迎指教。

在我看来,如果将产品运营作为一项整体工作,那么这项工作主要分为四个阶段或者说四个步骤,分别为产品运营的前提基础、产品设计、运营上线、和结果复盘。

一、产品运营的前提基础

产品运营的前提基础包括三项内容:信息收集、数据分析、以及结合当前情况作出的综合判断。

1. 信息收集

信息收集可以分为三个方面:

  1. 渠道:这里渠道指的是不同的用户来源,比如广告用户、affiliate或reseller用户、外部站点用户等,不同渠道的用户会具有不同的特点,需要针对不同方向进行分析,这是后续分析思路的基础;
  2. 网站:这里指的网站是我们自己的官方网站,在充分考虑网站性能的情况下,要尽可能收集尽量全面的信息数据;
  3. 客户端:客户端则是指安装在用户设备上的程序,如果该产品是网页端产品,那么网站的信息收集应当同样兼顾到这里的内容。

下面我们来针对这三方面分别进行详细解释和说明。

渠道:

之所以将渠道单独作为一个重要的方面,是因为不同渠道的用户在程序内部的表现具有明显差异,举个例子:如果SEO非常优秀,网站内容精准符合用户场景,那么进入产品的用户会具有极高的转化率,而相反的,如果通过Tik Tok娱乐主播推广PC端杀毒产品,那么产品内的数据就会很难看。

因此,一定要通过信息收集确定用户渠道。同时,了解业务渠道对于产品运营来说是非常重要的,至少要清楚掌握用户来源,根据用户特点才能进行下一步的数据分析。

网站:

对于海外产品运营来说,网站的信息收集主要通过三种方式进行:

  1. GA/GA4;
  2. 自主埋点跟踪;
  3. 其它工具:SEMrush、ahref、hotjar等。

GA/GA4:

海外运营最常遇到的应该就是GA/GA4的信息收集了,GA和GA4的部署方式是不同的,包括其中可能还会涉及到GTM(Google Tag Manager),由于本文为产品运营,所以具体的部署方法这里就不展开了,而且GA的服务也快停止了,大家还是抓紧时间部署GA4吧。以下内容就不写GA了,只写GA4。

GA4可以跟踪的信息主要分为两种,一种是预定义的信息,比如:维度的话包括流量来源、默认渠道分组等,指标的话可以有会话数、事件数、跳出率、停留时间等,GA4的预定义内容其实已经覆盖了大部分基础信息的收集了。另一种则是自定义信息,这类信息往往是对业务本身非常重要的内容,比如:自定义转化事件、自定义用户群组等。下面分别具体说明一下。

预定义的信息收集中首先是网站流量数据的统计,这可以说是最基础同时也是最重要的数据之一了。流量是指访问网站的用户数,不同的维度上会有不同的统计方法,这个数据会出现比较大的差异,这个差异出现的原因可以参考pv与upv的不同;根据GA4的预定义信息收集,我们可以观察整个网站的流量大小,也可以添加一些筛选条件观察特定情况下的流量变化。在我们确定了筛选条件后,我们可以通过一些指标来观察流量的质量情况,这些指标包括但不限于:来源、跳出率、停留时间等;通过这些指标,我们可以很快判断出需要优化的点,比如:如果来源全部集中于referral,则说明过于依赖外部跳转;或者,如果跳出率高、停留时间短,则说明用户可能是错误地来到了网站或者网站提供的内容与用户的需求严重不符,等等。

预定义的信息收集中还有用户特征的数据也是非常重要的,GA4会在权限内相对详细地收集用户的信息,比如:国家/地区、语言、操作系统、浏览器版本等,而且它还可以根据用户在其它途径登记的信息统计出访问网站的用户比例,他们是生理男性还是生理女性,是在哪一个年龄段,有着怎样的兴趣爱好。这对于网站和产品设计来说有着巨大的意义。

自定义的信息收集则是网站的运营者和管理者从自身的角度出发,在预定义指标没有覆盖的情况下,根据GA4规则自主设计的事件上报。这种规则可以是之前GA使用的每个交互详尽埋点,也可以是通过GTM规则埋点,还可以是数据层(data layer)的埋点。信息收集的方法还是尽量不要重复部署为好,这有可能造成数据的重复收集,即使能够区分出哪一组数据是用什么方法收集的,这些数据也很容易相互干扰。

自定义的信息收集中必须要明确的就是转化事件,这是一个相对复杂的定义,不同的网站会有不同的转化事件,同一个网站从不同的角度出发也会需要定义不同的转化事件;举个例子:如果想要统计一个功能按钮的使用情况,我们可以通过事件名称(event name)、事件类别(event category)、事件标签(event label)来进行信息收集,也可以直接将这次交互行为直接定义为转化事件单独进行统计。

自主埋点:

有些网站的信息跟踪可能不仅有GA/GA4,还有其它的一些自主埋点信息收集,甚至可能完全不使用GA/GA4,信息收集全部凭借自主埋点完成。如果是这种情况,对网站运营者或者管理者的能力以及开发人员的技术能力要求是非常高的,绝大部分时候都不推荐这样做,因为信息收集很容易牵扯到法律问题,尤其是在GDPR上线之后,但如果使用GA/GA4等其它工具则可以规避掉这些风险,而且自主信息收集往往只针对当前网站上的用户信息特征,无法收集到类似GA4中提供的用户性别、年龄段以及兴趣爱好的特征。

自主埋点我接触到的比较少,主要是以某个特定功能的单独监控为主,通常是用来辅助运营判断的信息。在自主埋点信息收集时,还需要有容器储存这些信息,这就无形之中或多或少增加了运营成本。

其它工具:

除了常规的GA/GA4信息收集、自主埋点信息收集,我们还可以在具有某些特定需求时使用其它工具:我们可以通过SEOrush或者ahref去了解一个网站的大体情况,分解分析这个网站的内容建设方向、流量来源、外部链接建设倾向、广告投放倾向等等;我们还可以通过hotjar、vow这类的测试辅助工具实现诸如热力图监控、A/B测试等运营方案。

客户端:

如果产品有客户端,那么客户端的信息收集也需要进行部署,现在市面上有很多成熟的工具可以使用,信息收集部署可以像在网站部署GA4一样实现;当然,我们也可以使用自主信息收集部署,不论哪一种方式,只要可以充分地进行信息收集,都没有问题。

自主埋点:

我接触到的更多是自主埋点的信息收集,整个程序中每一个交互点都需要做到信息收集,这可能是一个非常庞大的工作量,但这一定是必要的也是值得做的,只有这样做才能更加全面地观察到用户在程序中的完整生命周期,也更容易通过不同属性用户体现出的不同特点完善用户画像,实现产品的精细化运营。

具体的信息收集方式每个公司各有不同,但在信息收集中,有非常重要的一个环节可能是大家忽视了或者无法实现的,那就是客户端数据和网站数据的贯通。有些公司的运营网站和程序之间是相互独立,或者说是二者是割裂的,如果双方经常沟通,交换意见,事情倒是并不严重;而一旦双方缺少沟通,分别朝着不同的方向狂奔,整件事情就没那么容易收场了。因此个人认为在信息收集中一定要特别注意数据的传递和贯通。

暂时我能想到的关于信息收集的内容就是这么多了,内容多有疏漏,欢迎大家的批评指正;信息收集完成之后,我们就可以进行下一步了——数据分析了,下次更新说这个。

本文由 @吴桐 原创发布于人人都是产品经理。未经作者许可,禁止转载。

题图来自Pixabay,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。