别开发微信公众号是合理的应用号可能会长什么样容我慢慢道来
发表时间：2023-09-22 07:02:49
文章来源：炫佑科技
浏览次数：176
菏泽炫佑科技
别开发微信公众号是合理的应用号可能会长什么样容我慢慢道来
吴杰森
阅读这篇文章
大约需要
10
分钟
“别再开发应用了，做个公众号就行了。”
这是我*近对所有正在创业的朋友说的话。 应用生态已经饱和，低频产品没有必要开发应用。 相反，开发微信公众号（未来的应用号）将是*好的选择。
八年前，当有人告诉你先开发移动应用程序，然后再开发 PC 时，你会认为这是一个笑话。 2年前，如果有人告诉你先开发一个微信公众号，然后开发一个应用程序，*后开发一个简单的PC产品，你可能会觉得这又是一个笑话。 现在，如果我告诉您六个月后，您真的不必再开发应用程序了，我不是在开玩笑。
这篇文章会告诉你两件事：
为什么只开发微信公众号才合理？
申请号可能是什么样子
让我慢慢告诉你吧。
我们先从一个案例开始
不久前，我和朋友在一家快餐店吃饭。 突然来了一个外国人。 他向我的朋友打了招呼，于是我们坐下来互相认识了。 这个外国人叫Drew，他的中文说得比我的英语还流利。 他是一名产品经理。 当他知道我认识张小龙时，他笑得合不拢嘴。 他说，
”
我是张小龙的粉丝。 我认为微信就是全世界。 现在，我们只需要开发微信公众号，不需要开发iOS和微信。
”
他是《悠力英语口语》的产品经理。 悠力英语口语是一款真人英语教育产品。 它是一个完全基于微信的产品。 它是严格意义上的“微信应用”，与大多数微信公众号不同。 同样，Yoli 也不是一个简单的HTML 5应用程序，而是拥有相当庞大的产品和交互系统。
Yoli的口语产品分为两个端：学生端和教师端。
在学生方面，他们使用微信服务号。 学生可以购买 Yoli 课程。 购买后，Yoli 会利用 Uber 的抢单模式为学生和老师匹配：
学生可以在服务号中与老师对话，按照规划的课程进行互动学习和练习英语。
他们使用教师端的企业帐户。 老师可以在企业账号上抢单、授课等：
每节课结束后，学生可以对老师进行评价。
从下图可以看到，教师端的所有功能都被打包到了企业账号中。
简单画出其产品架构如下：
当然，实际的架构比上图复杂得多。
这是我见过的“*全”的微信公众号。 而且，Drew 等人无意开发 iOS 或应用程序。 对于他们的产品团队来说，他们认为只开发微信公众号就足够了。
Yoli的口语给了我很多启发。 正如引文中提到的，2年前，如果有人告诉你只开发微信公众号，你肯定会觉得不可思议，但现在，微信上出现了功能复杂的公众号。 申请账号将于近期开放。 为什么我们不优先发展或者只发展微信公众号？
微信公众号一定是未来
本文提到的微信公众号属于功能性较强的公众号。 虽然订阅账号也可以接入开发接口，但从产品角度来看，未来的大部分开发将不可避免地基于服务账号和即将到来的“应用账号”。 或许可以统称为“微信app”。 简单的定义是：
”
完全基于微信开发的消息或网络应用程序，以满足用户的某些需求。 入口是公众号。 用户无需离开微信即可完成所有操作，所有需求都在公众号中得到满足。
”
重申一下，这里所说的“微信小程序”并不是指“也许”公众号那样的“自媒体”，而是一个完整的闭环功能产品。 例如，如果您开发了一款iOS应用程序，然后您注册了一个订阅号并每天发布文章来推广该产品app开发，那么这个订阅号就不能被定义为“微信应用程序”。
从很多角度来看，开发微信公众号比开发iOS和App更好。
2.1
用户在哪里，产品就在哪里
如果你是卖鞋的商人，而你的鞋只适合南方人，你就应该在南方开店，或者在南方人常去的地方、网站上投放广告。
”
无论您的客户在哪里，让他们看到您。
”
对于绝大多数中国移动互联网用户来说，他们（我们）大部分时间都花在微信上。 例如，过去7天，微信在前台工作了16.6小时（自成统计），这意味着我有2个多小时在微信上度过。
因此，对于大多数产品来说，我们的目标用户也是微信用户。 那么，为什么不在微信中开发产品，让我们的产品更容易触达用户呢？
2.2
从使用频率角度开发
打开手机，查看手机的电池统计信息。 你会很容易发现微信在你的电池使用中所占的比例*大。
通过查看过去7天的统计数据，我还发现，在我的电脑上安装的总共218个应用程序中，我在过去一周只使用了28个，其中8个是系统应用程序，也就是说，我只使用了28个应用程序。打开了20个第三方应用程序。 。 而耗电量超过1%的只有10个。 我们假设功耗超过1%的应用是高频应用，那么：
”
我一周经常使用的应用程序只有 10 个，仅占我安装的应用程序的 4%。
”
我相信非IT领域的人肯定没有我安装的应用程序那么多，但经常使用的应用程序数量也只有10个左右。
这意味着大多数应用程序都不经常使用，而不经常使用的命运很有可能被“删除”，因为与删除微信好友不同，删除应用程序确实可以节省大量内存。
那么，低频应用如何避免被删除呢？ 然后占用手机上尽可能少的空间。
如何做呢？ 创建微信公众号。
当用户关注微信公众号时，相当于“下载”了一个应用程序，但无需等待下载时间，也不占用手机内存。
2.3
从促销角度思考
想象一下这样的场景：你的产品要在当地进行推广，你在路边分发传单。 是扫描二维码下载路人更有可能下载的100MB应用程序，还是关注公众号？
答案是显而易见的。
虽然如今推广和下载应用程序或公众号的成本非常高，但公众号的优势在到达用户手中的那一刻就显现出来了。 “无需下载”无论从哪个角度，都让人心理不那么舒服。 这是一个负担。 无论如何，只要你遵循它，你就不会损失金钱。 如果您关注后不喜欢，可以立即卸载。 但如果你下载了一个应用程序但你不喜欢它，你会后悔浪费数据和下载时间。
2.4
从营销的角度来思考
因为朋友圈的存在，用户使用产品和参与传播发生在同一个地方别开发微信公众号是合理的应用号可能会长什么样容我慢慢道来，这意味着使用同样的营销方式，用户参与传播的转化率更高，因为传播路径变得更短。
更重要的是，作为微信应用，除了向用户提供功能之外，还可以推送内容。 如果使用服务号，用户的微信上会额外多出一个未读标记。 这是一种比应用程序到达率更高的推送方式——因为用户很有可能关闭应用程序的推送，但一般不会关闭微信推送。
2.5
考虑开发成本
微信公众号的开发涉及Web前端和服务器后端。 与iOS和开发相比，节省了至少两个平台的开发成本，节省了大量的时间和人力。 因为为这两个平台开发客户端，服务器后端开发几乎是必要的。 Web前端可能比微信公众号少，但相比之下，这些前端的工作量比客户端要少得多。
如果你打算做一个产品，找一家外包公司开发app，如果他们推荐你先开发一个微信公众号，那一定是一家不错的外包公司。
2.6
考虑适应成本
在微信应用中，无论用户使用哪种手机，获得的体验都是一样的。 如果不一致，可以用相对较低的开发成本使其一致。
如果你是一名应用测试人员或产品经理，你肯定会讨厌它，因为有这么多不同尺寸、性能和分辨率的设备，给开发和测试带来巨大的工作量。
如果你正在开发微信消息应用，微信提供了固定的消息模板，这意味着无论用户使用什么系统，他们看到的界面都是相同的。
如果您正在开发Web应用程序，只需针对不同的屏幕尺寸稍微调整前端代码，用户就会获得统一的体验。 与针对不同设备进行调整相比，前端调整的成本几乎可以忽略不计。
2.7
从精益创业的角度来思考
精益创业简单来说就是小规模试错，然后迭代，再试错，再迭代，*后成功。 这是当今在互联网上创业的基本方法。
基于微信开发产品更符合精益创业的理念。
存钱
开发成本更低、速度更快、迭代更快
修改无需等待审核。 迭代完就可以立即看到效果，然后继续观察迭代。
用公众号创业、找投资，不会让人觉得可笑。 相反，这是一个更精简的开始。
2.8
也证明了这一点
大约两三年前（具体时间我记不清了），聊天功能被独立出来，做成了微信刚推出时的形式：聊天和群组。
半年前，该项目已上线。 中文是“公众号”。 除了在这里聊天之外，用户还可以关注 CNN 看新闻、买鞋：
如上图所示，CNN的机器人（相对于微信公众号）可以根据我发送的关键词向我推送新闻。 我可以从我关注的 Shop 机器人中订购菜单，然后直接去买鞋子。
不久前，曾经写过微信如何改变中国互联网的老外——微信产品经理Dan跳槽了。 我不知道他是否对此负责，但有一点是肯定的，他注意到了微信，并试图从微信中学习一些东西。
因此，我们也在尝试让第三方以“聊天工具”的方式为用户提供服务，而不是开发单独的App。
这是趋势。
这一次，中国领先于美国。
但基于微信开发也存在几个问题
与开发iOS和App相比，仅开发微信公众号会存在一些问题。
3.1
纯Web应用程序效率不够
我们不能只开发一个像Siri这样的“机器人”公众号，因为这样的体验在很多场景下是非常低效的。 更多场景下，我们通过点击找到我们想要的功能。
点击基本上都是在网页上进行的。 该网页是使用HTML5开发的。 浏览是否流畅与网络速度和页面内容量有关。 与原生应用程序不同，除了要加载的内容之外，其他控件都是本地化的。 的。
更可怕的是，如果没有网络，微信公众号将不复存在，因为无法离线使用。
从这个角度来说，原生应用比微信公众号更好。
3.2
要想赢得新人，只能靠自己
App Store有编辑推荐机制和排行榜，让每个App除了自己的渠道之外，还能获得额外的推广入口。 同样，国内每个市场都有促销点。
但微信从未推广过任何官方账号。 每个公众号只能靠自己，平台不会给你引流。
即使应用号上线后，微信平台短期内也不宜推广任何第三方应用号。 我坚信这一点。
3.3
无法获取用户信息和好友关系
使用微信登录。微信向每个产品返回用户的个人资料图片、昵称、性别、语言和城市，但没有其他信息。 与使用微信登录不同，微信不会返回用户的好友关系。
如果您开发一个应用程序并与另一个应用程序相互推广，您可以在推广过程中交叉检查用户数据，以制定更好的营销策略。
但在两个不同的微信公众号中，你无法查看关注者的重叠程度。 除非两个公众号在同一个开发者账号下。 因为每个公众号的用户资料都是不同的。
诸多限制会导致您在用户登录后仍然需要开发相关功能来收集用户信息（如手机号码、邮箱地址等），以进行更有针对性的营销和开发功能。
3.4
营销限制
微信上有很多公众号被封。 在被封的公众号中，*受关注的一类就是“诱导分享”。
不久前，易到用车的一项营销活动被微信定义为“诱导分享”并被禁止。
要想在微信平台上生存，就必须遵守微信的规则，而“诱导分享”是开发者*讨厌的规则——哪个产品不希望用户更多地分享？ 哪个产品不会促使用户与朋友分享？
然而，微信并不希望营销活动降低其朋友圈的质量。
这就需要一个平衡，但是这个平衡是非常困难的，这往往会让开发者感觉不舒服，导致投诉。 要么，想办法在微信的规则内生存，要么思考如何通过其他渠道来玩。
3.5
会话列表中的条目组合
微信服务号的对话就像朋友的对话一样混合在一个列表中。 虽然“通讯录”中有公众号的专门入口，但里面的公众号并不能自由排序。
这意味着用户无法在手机桌面上自由移动图标，无法将常用图标放在**屏，也无法对其进行分类。
这会减少公众号的留存，因为用户需要通过层层结构来搜索或找到自己之前关注过的公众号。
Web 应用程序是否有可能变得更快？
从技术角度来看，阻止更多人“只”开发微信公众号的原因可能是：
HTML5 网页加载缓慢
离线时不可用
那么，有没有办法解决这个问题呢？
4.1
耐克广告灵感
里约奥运会**天，我的朋友圈就充斥着耐克的这则广告：
屏幕之所以刷新，并不是因为广告内容，而是因为它的加载速度，看起来很像微信原生功能。
随后，微信官方发布声明称，这是微信的“原生广告”，加载速度比之前快了10倍。 不知道他们如何衡量这个倍数。
该广告加载速度如此之快是因为：
*新版本的微信应用程序集成了用于显示此广告的控件。 也就是说，这个广告并不完全是一个HTML5网页，部分结构是微信客户端原生的。
当用户收到广告但没有打开（朋友发给你，或者你即将在朋友圈看到）时，广告已经在加载，而不是点击后加载。
虽然微信尚未正式公布“原生广告”的原理，但上述猜测基本一致。
换句话说，Web 应用程序的加载速度也可以与本机应用程序一样快。
4.2
来自网络应用程序的灵感
我将从一些比较晦涩但有趣的事情开始。
它长期以来一直致力于推动网络应用程序的发展。 它鼓励开发者开发Web应用程序，并提供各种技术和API的支持。 然而，之前的解决方案并没有特别促进Web应用程序的发展，直到*近Web应用程序（PWA）的概念被推出。
PWA 是一个在浏览器中运行的应用程序。 这个概念实际上是一系列技术的封装。 直接翻译就很容易理解：渐进式Web应用程序。 我们不需要了解它背后的技术，我们只需要了解它能做什么：
立即加载。 加载速度可能会比以前快10倍以上，而且即使网速很慢，仍然可以拥有极高的可靠性。
体验很流畅。 操作网页就像操作原生应用一样流畅。
添加到主屏幕。 PWA 可以生成图标并添加到主屏幕。
推送通知。 即使浏览器关闭，用户仍然可以接收来自 PWA 的推送通知。
有反应。 适应各种屏幕和设备。
安全。 所有数据均通过 https 传输。
渐进式加载。 首先加载框架，然后填充内容。
离线使用。 没有互联网仍然可以使用。
之所以能做到这一点，是因为浏览器支持PWA。 *新版本 Opera 已经支持 PWA。 这些浏览器提供了一系列统一的API来允许渐进式Web应用程序（PWA）运行。
用一句话概括一下：
”
PWA是一个Web应用程序，但体验与原生客户端几乎相同。
”
不幸的是，PWA 尚不受支持。
4.3
Web应用的好时代已经到来
无论是耐克的微信广告，还是它所宣传的渐进式网页应用，都在告诉我们，网页应用可以快速加载，离线是可以的，网页应用可以媲美原生客户端，这意味着，微信公众号的体验肯定会变得越来越像原生客户端。
不得不提的是，如果你把手机调成飞行模式，然后打开广告，前面提到的耐克广告仍然会显示。
或许，微信已经支持类似PWA的技术了。
申请号会是什么样子？
距离微信宣布即将推出申请号已经快一年了。 无论从任何渠道，外界都没有人知道应用程序账号会是什么样子，会为开发者提供什么功能。
当我厚颜无耻地和微信团队讨论PWA时，他们回复我：我们会在组件和Web之间做到*好的平衡，保证应用的一致性和运行效率，同时兼顾开发的便利性。
结合这句话，从开发者的需求到PWA技术的启发，我们可以大致猜测微信应用号有哪些功能。
5.1
控制
从更快加载的角度来看，应用账号将为开发者提供一系列统一的控件。
这些控件可能是微信中嵌入的HTML前端控件，也可能是客户端上的原生控件，或者两者兼而有之。
例如，应用账户可以提供信息列表控件。 如果你是做新闻应用账号，只需要连接新闻数据，内容就会呈现在原生控件中。
再比如，如果你正在构建一个购物应用账号，那么你需要做的就是开发一个后端并连接API，这样产品就可以直接显示在原生列表框架中。
开发人员也许能够对本机控件进行一些自定义，但他们可能无法进行特别重大的更改。
5.2
强大的API
目前，微信为开发者提供了音频、分享等API。 从应用账号向原生应用靠拢的角度来看，微信可能会为开发者提供更多的线上和本地API。
比如图形界面、辅助操作、后台加载等。
这些接口将使应用程序帐户离线运行成为可能。
5.3
结合原生控件、前端技术和 Bot
前两点意味着微信应用号将接近原生App，具有更快的加载速度、本地计算能力、离线使用等，开发者可以根据自己的需求调整官方提供的原生控件。
对于自由度要求较高的应用，可能仍然需要大量的前端开发，但结合应用号的API，这些前端页面的加载可能还是很快的。
包括原来的Bot模式（即你向公众号发送消息，公众号返回图文信息），应用号将是原生控件、前端技术和Bot的结合体。
5.4
应用程序帐户互操作性
应用账户之间的数据互通可能会逐步实现。
*简单的是，一个应用程序帐户可以与另一个应用程序帐户共享内容。 像这样的东西：
更深入地说，您可以在申请号之间跳转。
更深入一点，应用程序帐户之间可能会共享特殊的存储空间。 就像这样，应用程序帐户可以专注于处理该空间中的文件。
5.5
更加开放的通知系统
目前，利用微信的客服界面，服务号可以向过去48小时内与该服务号互动过的关注者推送无数条消息，但要推送给所有人，每个月只能推送4次。
一个月推4次显然是不够的。
也许应用账户会降低推送限制，允许用户选择接收推送通知的频率，而不是统一限制所有服务账户每月只能推送4次——就像原生应用程序一样，如果应用程序的推送太强大，用户可以选择关闭。
如果是的话，微信可能会在客户端添加统一的通知管理界面。
5.6
打开桌面
还记得前面提到的 PWA 吗？ PWA 是响应式的，这意味着应用程序开发出来后，可以在手机或电脑上运行。
微信有版和Mac版（虽然已经几千年没有更新了）。 微信版客户端集成了订阅号，用户可以在电脑上查看订阅号的文章。
基于这样的推测，我们有理由相信，如果微信使用应用账号的机制与PWA类似，那么微信只需要在桌面客户端添加一个入口，应用账号就可以在桌面上运行。
对于开发者来说，开发移动版本就“赚”了桌面版本。
5.7
专用申请号录入，可排序分类
微信可能会在客户端提供专门针对应用账户的入口，就像现在的钱包功能一样：
用户可以根据自己的喜好对它们进行排序。
5.8
开发者工具
微信此前已经为服务号的开发者提供了网页调试工具，为应用号提供开发者工具可能是迟早的事。
5.9
也许会有用户好友关系？
或许好友关系会逐渐开放，因为好友关系是对第三方应用开放的，目前还没有出现任何问题。 如果腾讯足够开放，可能会打通用户的好友关系。 到时候申请号会更有趣。
5.10
再次强调，以上全是猜测。
我重申一下，我没有从任何微信员工那里获得有关申请号的详细信息，以上均为猜测。
这是一个新的机会
iOS及应用开发成本居高不下，推广困难。 从精益创业的角度来看，优先发展微信公众号是一个合理的选择。
渐进式Web应用技术的出现，让Web应用的体验更加接近原生应用。 Web 应用程序还可以快速加载并且可以离线。
无论用户在哪里，都应该开发产品。 当用户在微信时，应该开发一个“微信应用程序”。 从技术上来说，我们已经制定了合适的解决方案，剩下的就是等待申请号的到来。
在它到来之前，我们还是可以先基于服务帐号进行开发。 我相信微信会提供一个迁移方案。 如果等到申请账户开通后才开始准备，您可能会错过新的机会。
也许有一天，互联网公司的技术团队中会出现一个特殊的职位，叫做“微信开发工程师”。 你相信吗？ 我相信。
