wgs84转utm代码_真实的人不使用UTM代码

最新推荐文章于 2024-07-31 21:43:11 发布

weixin_26752759

最新推荐文章于 2024-07-31 21:43:11 发布

阅读量1.6k

点赞数

文章标签： python java

原文链接：https://medium.com/swlh/real-people-dont-use-utm-codes-30e6c12ea60

版权

wgs84转utm代码

Caveat: If you are in a marketing organization driving marketing campaigns, you should totally use UTM codes. For example, this post from Lee Hurst begs marketers to start using more UTM codes.

警告：如果您在负责行销活动的行销组织中，则应完全使用UTM代码。例如， Lee Hurst的这篇帖子恳求营销人员开始使用更多的UTM代码。

So why shouldn’t you use UTM codes?

那么，为什么你不应该使用UTM代码？

人工过滤 (Human filtering)

Every time we dive into social media (email, reddit, Twitter, LinkedIn, Facebook, …) our brains drown in a sea of information overload. We are in this site to find interesting links, but our brains have had to develop quick strategies to separate real content from ads.

每当我们进入社交媒体(电子邮件，reddit，Twitter，LinkedIn，Facebook等)时，我们的大脑就会淹没在信息过载的海洋中。我们在此站点中找到有趣的链接，但是我们的大脑不得不制定快速的策略以将真实内容与广告分开。

Which of these links would you rather click on?

您想点击哪个链接？

The answer is clear: The first one looks like a link that a friend would send to me. The second one looks like a link I would find on an email campaign. The third one tells me nothing, and will probably remain un-clicked.

答案很明确：第一个看起来像是朋友会发送给我的链接。第二个看起来像是我在电子邮件广告系列中找到的链接。第三个告诉我什么，并且可能会保持未单击状态。

These 3 links go to the same place, but the first looks way more trust-worthy than the rest.

这3个链接位于同一位置，但是第一个看起来比其他链接更值得信任。

机器学习过滤 (Machine learning filtering)

A savvy internet expert will quickly counter: “People don’t need to see the links, you can hide URLs behind text”.

精明的互联网专家会Swift反驳：“人们无需查看链接，您可以将URL隐藏在文本后面 ”。

That’s true — and there will be people that click on a link without first snooping into what URL is hidden behind. But not all filtering is done by human brains. Computers try hard to filter authentic links from noise for you.

没错-会有人点击链接而没有先窥探后面隐藏的URL。但并非所有过滤都是由人脑完成的。 计算机努力为您过滤掉噪音中的真实链接 。

Take email, reddit, Twitter, LinkedIn, Facebook: They all try to surface links that are interesting to you, while filtering out spam. They all use machine learning to look at a link and score how interesting it might be to you. All of these ML models have been fed millions of annotated links, and all of these models have learned: If the link has an UTM code or if the link goes through an URL shortener, the probability of spam is much higher.

以电子邮件，reddit，Twitter，LinkedIn和Facebook为例：它们都在过滤掉垃圾邮件的同时尝试显示您感兴趣的链接。他们都使用机器学习来查看链接，并为您评估链接的有趣程度。所有这些ML模型都已经获得了数百万条带注释的链接，并且所有这些模型都了解到： 如果该链接具有UTM代码，或者如果该链接通过URL缩短器，则垃圾邮件的可能性就更高 。

我们来看一些数据 (Let’s look at some data)

For example, on reddit.com/r/programming during a given month 491 links had a score>5. Only one of these links had utm codes embedded:

例如，在给定月份的reddit.com/r/programming上，有491个链接的得分大于5。这些链接中只有一个嵌入了utm代码：

Image for post — /r/programming links don’t use utm codes (except 1 of 491)

Same on Hacker News: Looking at all the links with score>5 during 2020 so far, only a very small proportion of them have UTM codes embedded:

同样在Hacker News上：到目前为止，查看所有得分大于5的链接，其中只有很小一部分嵌入了UTM代码：

What about shorteners? 260 bitly URLs have been submitted to Hacker News this year, and their average score is 0:

那起酥油呢？今年有260个URL提交给Hacker News，平均得分为0：

查询 (Queries)

SELECT fhoffa.x.median(ARRAY_AGG(score)) median_score, url LIKE '%utm%' with_utm, COUNT(*) c
FROM `fh-bigquery.reddit_posts.2019_08`  
WHERE score > 5
AND url>''
AND subreddit='programming'
GROUP BY 2;SELECT fhoffa.x.median(ARRAY_AGG(score)) median_score, url LIKE '%utm%' with_utm, COUNT(*) c
FROM `bigquery-public-data.hacker_news.full` 
WHERE EXTRACT(YEAR FROM timestamp)=2020
AND score > 5
AND url>''
GROUP BY 2;SELECT ROUND(AVG(score)-1,1) avg_score, url LIKE '%bit.ly%' is_bitly, COUNT(*) c
FROM `bigquery-public-data.hacker_news.full` 
WHERE EXTRACT(YEAR FROM timestamp)=2020
-- AND score > 5
AND url>''
GROUP BY 2
LIMIT 1000

UTM代码使重新共享内容变得更加困难 (UTM codes make it harder to re-share your content)

Whenever I want to re-share an interesting link, I do so. But the link I got has UTM codes, now I have to work harder: Before sharing said link, I will need to clean it up, and remove al the UTM noise from it. Even more, if re-sharers don’t remove the existing UTMs, then all your analytics will become messed up with the wrong attribution.

每当我想重新分享有趣的链接时，我都会这样做。但是我获得的链接具有UTM代码，现在我必须更加努力：在共享所述链接之前，我需要清理它，并从其中消除UTM噪音。更重要的是，如果再共享者不删除现有的UTM，那么您所有的分析都将被错误的归因所困扰。

If you want top social media influencers to naturally share your links, help them do so with minimum effort. They know their shares will be more successful without UTM codes, so help them by giving them clean links.

如果您希望顶尖的社交媒体影响者自然地分享您的链接，请帮助他们以最小的努力。他们知道，如果没有UTM代码，他们的股份将更加成功，因此请给他们提供干净的链接来帮助他们。

酥油违反规定 (Shorteners are against the rules)

On Medium, their rules:

在Medium上，他们的规则是：

To prevent fraud and abuse, you must, you may not: Include shortened URLs in your posts.

为防止欺诈和滥用，您必须禁止以下行为：在帖子中包含缩短的URL。

In fact, one of my friends was recently banned from Medium. The only flaggable behavior we found on their posts was the use of bitly links.

实际上，我的一位朋友最近被禁止使用Medium。我们在他们的帖子中发现的唯一可鄙行为是使用位链接。

This because URL shorteners are commonly used by spammers and abusers.

这是因为垃圾邮件发送者和滥用者通常使用URL缩短器。

Quora seems to have similar policies (friends have had their content removed). And also people have strong negative reactions to UTM links. For example:

Quora似乎有类似的政策(朋友的内容已删除)。人们也对UTM链接产生强烈的负面React 。例如：

综上所述 (In summary)

If you are driving marketing campaigns, use UTM codes.
如果您要推动市场营销活动，请使用UTM代码。
If you are engaging in human-to-human conversations, don’t use UTM codes.
如果您要进行人与人之间的对话，请不要使用UTM代码。
To avoid your links getting tagged as spam, don’t use URL shorteners or UTM tags.
为避免您的链接被标记为垃圾邮件，请不要使用URL缩短器或UTM标签。
To measure results without UTM codes… well, that’s for a future post.
要在没有UTM代码的情况下测量结果……好吧，这是在以后的文章中。

想要更多？ (Want more?)

I’m Felipe Hoffa, a Developer Advocate for Google Cloud. Follow me on @felipehoffa, find my previous posts on medium.com/@hoffa, and all about BigQuery on reddit.com/r/bigquery.

我是Felipe Hoffa，Google Cloud的开发倡导者。跟随我的@felipehoffa ，发现我以前的帖子上medium.com/@hoffa ，以及所有有关的BigQuery上reddit.com/r/bigquery 。