乐搜 LetsTG 的核心产品定位,可以浓缩成一句话:面向中文用户的 Telegram 群组、频道搜索强力工具。它不只是把群组和频道放进一个目录,而是希望让中文用户输入关键词后,更快发现目标社群。增加中文品牌名“乐搜”以后,一个现实问题随之出现:怎样让原本只认识 LetsTG 的用户,理解“乐搜就是 LetsTG”?本文先讲清这款 Telegram 中文搜索工具的特点,再用可运行的认知迁移模型分析两个名字应该并列多久。文中参数均为情景假设,不是 LetsTG 的真实运营数据。
在这里插入图片描述

开篇:增加中文名很容易,完成认知迁移很慢

修改一个 Telegram 频道名称,只需要几秒;修改网站标题和 Logo,也可能只需要一次上线。但对乐搜 LetsTG 来说,这次变化并不是普通改名,而是要给一款 Telegram 中文群组频道搜索工具建立更明确的中文心智。

但品牌并不只存在于页面里,还存在于用户记忆中。

一个已经使用过 LetsTG 搜索群组或频道的用户,脑海里可能保存着下面这些信息:

  • 名字叫 LetsTG;
  • 官网是 letstg.com
  • 可以在搜索机器人 @letstgbot 中输入关键词查找群组和频道;
  • 看到 LetsTG 标识就知道是原来的产品。

当产品新增中文名“乐搜”时,页面可以当天完成升级,用户记忆却不会同步更新。用户至少要多次看到“乐搜 LetsTG”同时出现,才能逐渐建立一个新关联:

乐搜不是另一个产品,而是 LetsTG 的中文品牌名。

这就是双品牌过渡期存在的原因。

反复看到双品牌

只认识 LetsTG

知道乐搜 = LetsTG

看到乐搜也能认出原产品

搜索 LetsTG 仍能确认新品牌

真正的问题不是“页面什么时候改完”,而是“有多少用户已经完成了这次记忆更新,并把‘乐搜’与 Telegram 中文群组频道搜索建立联系”。

先看产品:乐搜 LetsTG 的“最强搜索工具”定位体现在哪里?

如果文章只讨论名字变化,却不解释产品能力,读者很容易把“乐搜”理解成一个普通中文商标。实际上,名称中的“搜”直接对应 LetsTG 最重要的使用动作:搜索 Telegram 群组与频道。

“Telegram 最强中文群组频道搜索工具”是一种鲜明的产品定位。要让这个定位可信,不能只重复“最强”,而要让用户看到它具体强在哪里。

产品特点 解决的问题 用户感受到的价值
中文关键词搜索 Telegram 原生搜索对中文主题发现不够直观 不必提前知道精确群名,也能按主题查找
群组与频道统一检索 群组、频道分散在不同链接和推荐列表中 一次搜索同时发现不同类型的公开社群
Telegram Bot 入口 用户已经身处 Telegram,不想反复切换应用 @letstgbot 中直接输入关键词搜索
官网导航入口 需要更完整的网页浏览、分类和外部发现路径 可以通过 letstg.com 浏览和继续筛选
搜索、导航与收录形成闭环 新群组和频道缺少被发现的入口 用户负责搜索,频道主可以提交,内容库持续扩展
“乐搜 + LetsTG”双品牌 中文名好记,英文域名和账号已有历史积累 中文用户容易理解,老用户仍能认出原产品

特点一:不是只按名称找,而是围绕中文需求找

很多用户并不知道某个 Telegram 群组的准确名称或 @username。他们只知道自己想找“AI 学习”“编程交流”“加密资讯”“影视讨论”之类的主题。

乐搜 LetsTG 的搜索价值,就在于把“我必须知道它叫什么”变成“我只要描述自己想找什么”。对中文用户而言,能够直接输入自然的中文关键词,是它区别于简单链接合集的关键。

特点二:群组和频道不再是两套查找流程

Telegram 群组偏交流,频道偏内容发布,但用户在产生需求时往往并不会先区分类型。他只想找到与主题相关、值得加入的公开社群。

乐搜 LetsTG 把群组与频道放进同一个发现逻辑中。用户先表达主题需求,再从结果中判断自己需要讨论群还是资讯频道,搜索路径更符合真实使用习惯。

特点三:机器人负责快,网页负责全

@letstgbot 适合 Telegram 内快速搜索:打开机器人、输入关键词、查看结果。官网则适合网页浏览、分类导航以及从搜索引擎进入。

这两个入口不是互相替代,而是覆盖不同场景:

中文用户想找 TG 资源

Telegram 内
@letstgbot 快速搜索

浏览器中
letstg.com 导航浏览

发现相关群组与频道

当一个工具既能留在 Telegram 内完成搜索,又有网页入口承接浏览和站外发现,它才不只是一个机器人,也不只是一个静态目录,而是一套更完整的搜索工具。

特点四:“乐搜”让最强功能被一眼看懂

LetsTG 保留了原有国际品牌、域名与账号识别,“乐搜”则把核心能力翻译成中文用户一眼能懂的动作。用户看到名称,就能联想到“快乐、轻松地搜索”,也能直接记住这是一个与搜索有关的工具。

因此,双品牌升级并没有改变产品主线,反而把产品主线说得更清楚:乐搜 LetsTG,就是为中文用户查找 Telegram 群组和频道而建立的搜索入口。

一、为什么不能第一天就只保留“乐搜”?

如果直接把所有 LetsTG 标识换成“乐搜”,新用户可能更容易理解,但老用户会面对一个身份确认问题:

  • 这是原来的 LetsTG 吗?
  • 原产品是不是停止运营了?
  • 我打开的是不是同名的新工具?
  • 原来的机器人账号为什么没有改?

这种疑问看似很小,却会增加点击、登录、搜索和分享时的犹豫。

更重要的是,旧品牌背后不只有用户记忆,还有大量已经存在的数字资产:

  • 官网域名;
  • Telegram 用户名;
  • 搜索引擎中的历史页面;
  • 第三方文章与外部链接;
  • 用户收藏、截图和聊天记录;
  • 过去积累的品牌搜索词。

完全替换旧名,相当于要求用户和搜索引擎在同一天完成迁移,现实中几乎不可能。

因此,当前“乐搜 LetsTG”的并列方式有两个明确作用:让新名字借助旧名字获得身份,让旧名字借助新名字增加中文含义;同时让“Telegram 中文群组频道搜索工具”这一产品特点进入用户记忆。

二、把用户认知分成三种状态

为了模拟过渡过程,我们先把受众分成三个状态。

状态 A:只认识 LetsTG

这类用户知道原英文品牌,但还没有建立“乐搜”与 LetsTG 的关系。看到单独的“乐搜”时,他们不一定能认出原产品。

状态 B:已经建立双品牌关联

这类用户知道“乐搜 = LetsTG”,也知道它是用于搜索 Telegram 中文群组与频道的工具。无论页面使用“乐搜 LetsTG”、只出现 LetsTG,还是在中文语境中简称“乐搜”,他们都能完成身份确认。

状态 C:流失或遗忘

部分用户在迁移期间不再接触品牌,或者随着时间推移忘记产品。这部分人既没有完成新旧关联,也不再保留稳定的旧品牌认知。

模型的目标,是观察状态 A 的用户如何逐周进入状态 B,以及“乐搜 LetsTG = Telegram 中文群组频道搜索工具”的完整认知需要多久才能建立。

只认识 LetsTG ──学习双品牌关系──> 知道乐搜 = LetsTG
       │                                 │
       └────────遗忘/流失────────────────┘

三、设置一组用于演示的初始参数

假设需要迁移的受众共有 10,000 人,初始状态如下:

用户状态 初始占比 对应人数
只认识 LetsTG 90% 9,000
已知道乐搜 = LetsTG 8% 800
已经流失或遗忘 2% 200

每一周,用户状态按照下面的参数发生变化:

learn_rate = 0.16           # 只认识旧品牌的人中,16% 建立双品牌关联
old_only_loss_rate = 0.01   # 只认识旧品牌的人中,1% 流失或遗忘
linked_loss_rate = 0.005    # 已建立关联的人中,0.5% 流失

同样必须强调:这些比例只是用于演示认知迁移机制,不是 LetsTG 的真实用户数据。

真实的学习率会受到很多因素影响,例如:

  • 官网是否持续展示“乐搜 LetsTG”;
  • 机器人、官方频道和交流群是否统一名称;
  • 用户每周接触品牌多少次;
  • 官方公告和第三方文章是否解释双品牌关系;
  • 产品属于高频工具还是低频工具;
  • 用户是老用户、活跃用户还是很久没有回访的人。

模型的价值不是预测一个确定日期,而是让“什么时候能撤掉旧名”从感觉题变成参数题。

四、用 Python 表示每周的迁移过程

核心状态更新只有几行:

def simulate(params, weeks=16):
    old_only = 0.90
    linked = 0.08
    lost = 0.02
    history = [(0, old_only, linked, lost)]

    for week in range(1, weeks + 1):
        learned = old_only * params.learn_rate
        old_lost = old_only * params.old_only_loss_rate
        linked_lost = linked * params.linked_loss_rate

        old_only = old_only - learned - old_lost
        linked = linked + learned - linked_lost
        lost = lost + old_lost + linked_lost
        history.append((week, old_only, linked, lost))

    return history

其中最关键的是 learned:每周有一部分只认识 LetsTG 的用户,因为看到了双品牌展示、官方说明或相关文章,开始理解“乐搜”和 LetsTG 的关系。

完整脚本运行方式:

python dual_brand_transition.py

脚本不需要安装第三方依赖。

五、默认情景:多久能完成大部分认知迁移?

在每周关联学习率为 16% 的假设下,模型得到下面的变化:

周数         只认识 LetsTG      知道乐搜=LetsTG      流失/遗忘
----------------------------------------------------------------
第  0 周          90.0%              8.0%              2.0%
第  1 周          74.7%             22.4%              2.9%
第  2 周          62.0%             34.2%              3.8%
第  4 周          42.7%             52.0%              5.3%
第  6 周          29.4%             63.9%              6.7%
第  8 周          20.3%             71.9%              7.9%
第 10 周          14.0%             77.1%              9.0%
第 12 周           9.6%             80.4%             10.0%
第 16 周           4.6%             83.5%             11.9%

按几个常见目标看:

关联认知达到 50%:第 4 周
关联认知达到 70%:第 8 周
关联认知达到 80%:第 12 周

这组结果给出了一个很有意思的观察:“过半用户已经知道”与“迁移基本稳定”不是一回事。

第 4 周,双品牌关联率已经达到 52%,看起来似乎可以宣布迁移完成。但此时仍有 42.7% 的用户只认识 LetsTG。如果马上停止并列展示,这批用户看到单独的“乐搜”时,仍可能无法确认身份。

到了第 8 周,关联率超过 70%,但仍有约五分之一的用户停留在旧品牌认知。

直到第 12 周,关联率才超过 80%,只认识旧品牌的人降到 9.6%。在这组假设中,这才更接近“多数用户已完成迁移”的状态。

当然,这不代表所有双品牌都应该固定并列 12 周。真正的结论是:不能把 50% 当作完成,也不能只看上线时间,应该看关联认知覆盖率。

六、为什么第 4 周撤掉旧名仍然太早?

把模型第 4 周的数据换算成人数:

已建立“乐搜=LetsTG”关联:52.0%,约 5,196 人
仍只认识 LetsTG:          42.7%,约 4,271 人
已经流失或遗忘:             5.3%,约   532 人

如果这时所有入口突然只写“乐搜”,4,000 多名仍依赖 LetsTG 识别产品的用户就失去了旧名称锚点。

他们并不一定永久流失,但需要额外完成一次确认:查看用户名、核对域名、询问朋友,或者搜索“乐搜是不是 LetsTG”。每增加一个确认步骤,就会产生新的转化损耗。

所以双品牌过渡期不是保守,也不是舍不得旧名字,而是在为用户保留一条连续的认知路径。

七、学习率不同,并列时间会差多少?

默认模型假设每周有 16% 的旧认知用户建立新旧关联。但现实中的传播速度可能更快,也可能更慢。

脚本分别测试 8%、12%、16% 和 20% 的每周关联学习率:

每周学习率       达到 50%       达到 70%       第 12 周关联率
----------------------------------------------------------------
8.0%              第 9 周        第 19 周             60.0%
12.0%             第 6 周        第 11 周             72.6%
16.0%             第 4 周         第 8 周             80.4%
20.0%             第 3 周         第 6 周             85.0%

差距非常明显:

  • 如果每周只有 8% 的人学会双品牌关系,19 周才能超过 70%;
  • 如果每周能达到 20%,第 6 周就能超过 70%;
  • 同样运行 12 周,最终关联率可能只有 60%,也可能达到 85%。

因此,“品牌并列三个月就够了”这种说法并不可靠。三个月只是时间,真正决定结果的是这段时间内有多少用户反复看到并理解双品牌关系。

八、怎样提高每周关联学习率?

模型里最值得运营团队主动改善的参数,就是 learn_rate

1. 所有核心入口保持同一顺序

例如统一使用:

乐搜 LetsTG

不要官网写“LetsTG 乐搜”,机器人写“乐搜导航”,交流群又只写 LetsTG。形式反复变化,会增加用户判断成本。

目前可用于身份确认的官方 Telegram 入口包括:

2. 不只展示名字,还要写一句关系说明

单纯把两个名字放在一起,部分用户可能误以为是联合品牌。过渡初期可以在关于页、公告或置顶消息里明确说明:

“乐搜”是 LetsTG 面向中文用户启用的中文品牌名,原官网、机器人和官方账号保持不变。

这句话能直接完成关系教学。

3. 在真实搜索动作中重复产品特点

比起单独发布改名公告,下面这种表达更容易进入记忆:

打开 Telegram 中文群组频道搜索工具“乐搜 LetsTG”:在 @letstgbot 输入关键词,即可查找相关群组与频道。

用户在完成搜索任务时,同时接收到品牌名、工具类型和具体用途。这样建立的不只是“乐搜 = LetsTG”,而是更完整的认知:乐搜 LetsTG = Telegram 中文群组频道搜索入口。

4. 让第三方内容也采用标准名称

教程、评测、使用指南和社交媒体介绍第一次出现时,可以统一写成“Telegram 中文群组频道搜索工具——乐搜 LetsTG”。这既扩大双品牌关系的覆盖面,也持续强化产品特点。

5. 保持一段足够长的重复周期

品牌认知需要重复。今天看一次、一个月后再看一次,与连续几周在官网、机器人和频道中看到同一名称,学习效果完全不同。

九、什么时候可以考虑缩短为“乐搜”?

模型不能给所有产品一个固定周数,但可以提供一组判断信号。

信号一:关联认知测试达到目标

对老用户展示“乐搜”,询问他们是否知道它与 LetsTG 的关系。如果目标是 80%,就应该以真实测试是否达到 80% 为准,而不是以日历时间为准。

信号二:中文品牌搜索稳定增长

观察“乐搜”“乐搜 LetsTG”等查询是否持续产生,并且能正确指向官网或官方机器人。

除了品牌词,还可以观察“Telegram 中文群组搜索”“Telegram 频道搜索工具”“TG 群组频道导航”等功能词是否开始与乐搜 LetsTG 同时出现。品牌词代表用户记住了名字,功能词代表用户理解了它为什么值得使用。

信号三:客服和社区中的身份疑问下降

如果仍频繁有人问“乐搜是什么”“是不是原来的 LetsTG”,说明迁移尚未完成。

信号四:旧品牌仍保留可追溯位置

即使中文界面开始简称“乐搜”,关于页、页脚、结构化数据和官方说明中仍可以保留 LetsTG,方便旧用户和搜索引擎确认。

信号五:关键入口不依赖猜测

官网域名与 Telegram 用户名仍然是 LetsTG 体系,因此在提供链接的位置,最好继续完整写出“乐搜 LetsTG”或准确账号。

十、一个更稳妥的三阶段过渡方案

结合模型,可以把品牌迁移分成三个阶段。

第一阶段:强绑定

适合刚上线中文名时:

  • 标题、Logo 旁、简介首句统一使用“乐搜 LetsTG”;
  • 官方公告解释两者关系;
  • 所有入口同时更新;
  • 不单独使用“乐搜”替代产品全称。

目标是尽快提高每周关联学习率。

第二阶段:中文名优先,英文名确认

当多数活跃用户已经建立关联后:

  • 中文页面以“乐搜”为主要称呼;
  • 标题、页脚或入口处继续保留 LetsTG;
  • 教程首次出现仍写“乐搜 LetsTG”;
  • 搜索和客服继续观察身份混淆。

目标是强化中文心智,同时保持旧认知连续。

第三阶段:按场景灵活简称

当关联测试、品牌搜索和社区反馈都表明迁移稳定后:

  • 中文日常文案可以简称“乐搜”;
  • 国际页面继续使用 LetsTG;
  • 涉及域名、账号、SEO 和官方身份时保留完整名称;
  • 关于页长期保留双品牌对应说明。

目标不是消灭 LetsTG,而是让两个名字在各自最合适的场景工作。

十一、模型的边界

这套模型为了容易理解,做了几项简化。

用户并不一定每周接触品牌

模型把学习率压缩成一个比例,现实中它由曝光次数、渠道、内容形式和用户活跃度共同决定。

已建立关联的人也可能记忆变弱

模型设置了 0.5% 的每周流失率,但不同产品的遗忘速度可能相差很大。

新用户会持续进入

本文主要模拟原有受众的认知迁移,没有加入每周新用户。真实系统中,新用户可能一开始就接触“乐搜 LetsTG”,不需要经历纯旧品牌阶段。

不同用户群应分开观察

高频使用机器人、订阅官方频道的人迁移更快;只从搜索引擎偶尔进入的人迁移更慢。把所有人放在一个比例里,只适合做机制演示。

因此,不应拿“第 12 周达到 80%”直接制定真实改名计划。正确用法是用调研和分析数据替换参数,再观察自己的迁移曲线。

小结

  • 页面名称可以当天修改,用户记忆却需要多次接触才能完成迁移;
  • 乐搜 LetsTG 的核心特点,是面向中文用户统一搜索 Telegram 群组与频道,并同时提供机器人和网页入口;
  • “Telegram 最强中文群组频道搜索工具”的定位,需要用中文关键词检索、群组频道统一发现、Bot + 官网双入口和搜索收录闭环来支撑,而不是只重复口号;
  • 双品牌过渡的核心,是让“只认识 LetsTG”的用户逐渐理解“乐搜 = LetsTG”;
  • 本文模型把受众分为只认识旧品牌、已建立双品牌关联和流失/遗忘三种状态;
  • 在默认假设下,关联认知第 4 周超过 50%、第 8 周超过 70%、第 12 周超过 80%;
  • 第 4 周虽然已经过半,仍有 42.7%、约 4,271 人只认识 LetsTG,过早撤掉旧名会造成身份确认成本;
  • 每周关联学习率从 8% 提升到 20% 时,达到 70% 关联认知所需时间可从 19 周缩短到 6 周;
  • 真正应该优化的不是某个固定并列天数,而是名称统一、关系说明、入口一致和重复曝光;
  • 是否进入下一阶段,应看关联测试、品牌搜索和用户疑问,而不是只看上线了多少周。

完整脚本见 dual_brand_transition.py,只依赖 Python 标准库。修改初始认知比例、每周学习率和流失率,就能模拟不同传播强度下的品牌迁移周期。

双品牌升级最忌讳的,是页面已经向前走了,用户记忆却被留在身后。“乐搜 LetsTG”并列展示的意义,就是在新名字和旧认知之间搭一座桥,同时把产品特点说得更直接:它不是普通 Telegram 导航名称,而是帮助中文用户搜索群组、频道和公开社群的强力工具。

当用户看到“乐搜”就想到 Telegram 中文群组频道搜索,看到 LetsTG 就认出官网、机器人和原有品牌资产,这次升级才真正完成。所谓“最强”,最终也要落在用户能否用更少步骤、更自然的中文关键词,找到自己真正需要的群组与频道上。

"""
双品牌认知迁移模型:模拟用户从“只认识 LetsTG”过渡到
“知道乐搜与 LetsTG 是同一品牌”的过程。

所有参数均为解释机制的情景假设,不是 LetsTG 的真实运营数据。
运行:python dual_brand_transition.py
无第三方依赖。
"""

from dataclasses import dataclass


AUDIENCE = 10_000
WEEKS = 16
INITIAL_OLD_ONLY = 0.90
INITIAL_LINKED = 0.08
INITIAL_LOST = 0.02


@dataclass(frozen=True)
class Parameters:
    learn_rate: float = 0.16
    old_only_loss_rate: float = 0.01
    linked_loss_rate: float = 0.005


def simulate(params, weeks=WEEKS):
    old_only = INITIAL_OLD_ONLY
    linked = INITIAL_LINKED
    lost = INITIAL_LOST
    history = [(0, old_only, linked, lost)]

    for week in range(1, weeks + 1):
        learned = old_only * params.learn_rate
        old_lost = old_only * params.old_only_loss_rate
        linked_lost = linked * params.linked_loss_rate

        old_only = old_only - learned - old_lost
        linked = linked + learned - linked_lost
        lost = lost + old_lost + linked_lost
        history.append((week, old_only, linked, lost))

    return history


def pct(value):
    return f"{value * 100:.1f}%"


def first_week_at(history, target):
    for week, _, linked, _ in history:
        if linked >= target:
            return week
    return None


def print_main_scenario():
    params = Parameters()
    history = simulate(params)
    checkpoints = {0, 1, 2, 4, 6, 8, 10, 12, 16}

    print("双品牌认知迁移模型(情景假设,非真实运营数据)")
    print(f"初始受众:{AUDIENCE:,} 人")
    print(
        f"初始状态:只认识 LetsTG {pct(INITIAL_OLD_ONLY)},"
        f"已建立双品牌关联 {pct(INITIAL_LINKED)},流失 {pct(INITIAL_LOST)}"
    )
    print(
        f"每周关联学习率 {pct(params.learn_rate)},"
        f"旧认知流失率 {pct(params.old_only_loss_rate)},"
        f"已关联人群流失率 {pct(params.linked_loss_rate)}\n"
    )
    print(f"{'周数':<8}{'只认识 LetsTG':>18}{'知道乐搜=LetsTG':>20}{'流失/遗忘':>16}")
    print("-" * 66)
    for week, old_only, linked, lost in history:
        if week in checkpoints:
            print(
                f"第 {week:>2} 周"
                f"{pct(old_only):>18}"
                f"{pct(linked):>20}"
                f"{pct(lost):>16}"
            )

    print("\n目标到达时间")
    for target in (0.50, 0.70, 0.80):
        week = first_week_at(history, target)
        result = f"第 {week} 周" if week is not None else f"{WEEKS} 周内未达到"
        print(f"关联认知达到 {pct(target)}{result}")

    return history


def print_sensitivity():
    print("\n" + "=" * 66)
    print("敏感性分析:不同每周关联学习率,需要并列展示多久?")
    print("=" * 66)
    print(f"{'每周学习率':<16}{'达到 50%':>14}{'达到 70%':>14}{'第 12 周关联率':>18}")
    print("-" * 66)

    for learn_rate in (0.08, 0.12, 0.16, 0.20):
        history = simulate(Parameters(learn_rate=learn_rate), weeks=24)
        week_50 = first_week_at(history, 0.50)
        week_70 = first_week_at(history, 0.70)
        linked_week_12 = history[12][2]
        w50 = f"第 {week_50} 周" if week_50 is not None else "24 周未达"
        w70 = f"第 {week_70} 周" if week_70 is not None else "24 周未达"
        print(
            f"{pct(learn_rate):<16}"
            f"{w50:>14}"
            f"{w70:>14}"
            f"{pct(linked_week_12):>18}"
        )


def print_early_stop(history, stop_week=4):
    week, old_only, linked, lost = history[stop_week]
    print("\n" + "=" * 66)
    print(f"如果第 {stop_week} 周就停止并列展示")
    print("=" * 66)
    print(f"已建立“乐搜=LetsTG”关联:{pct(linked)}(约 {linked * AUDIENCE:,.0f} 人)")
    print(f"仍只认识 LetsTG:          {pct(old_only)}(约 {old_only * AUDIENCE:,.0f} 人)")
    print(f"已经流失/遗忘:            {pct(lost)}(约 {lost * AUDIENCE:,.0f} 人)")
    print("结论:此时撤掉 LetsTG,仍会让大批尚未完成迁移的老用户失去识别锚点。")


def main():
    history = print_main_scenario()
    print_sensitivity()
    print_early_stop(history)


if __name__ == "__main__":
    main()

Logo

DAMO开发者矩阵,由阿里巴巴达摩院和中国互联网协会联合发起,致力于探讨最前沿的技术趋势与应用成果,搭建高质量的交流与分享平台,推动技术创新与产业应用链接,围绕“人工智能与新型计算”构建开放共享的开发者生态。

更多推荐