在 dev.to 上发帖的最佳时间是什么时候？一个有数据支持的答案 🕰🦄🤷‍♂️ 收集数据：我们现在有什么？丰富数据 一点点数据可视化分析

2025-05-24

在 dev.to 上发帖的最佳时间是什么时候？有数据支撑的答案 🕰🦄🤷‍♂️

收集数据：

我们现在有什么？

丰富数据

有点数据可视化

分析

dev.to 是一个很棒的博客平台，几年前刚刚出现。我喜欢在上面写作，也喜欢阅读上面发布的内容。但我最喜欢的，我想也是大家最喜欢的，是在这个平台上建立起来的社区。

众所周知，社区会通过各种点赞和评论与发帖人进行大量互动。dev.to 上没有“karma”（卡玛）功能，但衡量帖子受欢迎程度（即评分）的一种方法是查看该帖子与社区的互动次数。

评论数，当然还有点赞数，在平台上分为3个类别：独角兽🦄、点赞❤和书签📕。

我最近想知道，一天中某个特定时间发布的文章是否会比其他时间表现更好。如果答案是肯定的，那么什么时候发布博文才能让尽可能多的人阅读呢？我有一些直觉，但我希望有证据和事实作为佐证。

以下是我所做的：

收集数据：

这里我就不多说了，因为以后我会写一篇更长的文章来详细解释如何有效地收集这类数据。

我最近注意到，查看 dom 时，每篇文章都有一个可用的公共 ID。

我还知道有一个公共端点允许您获取如下所示的用户信息：

http https://dev.to/api/users/<user_id>
Enter fullscreen mode Exit fullscreen mode

因此，我自然而然地尝试对文章做同样的事情......

http https://dev.to/api/articles/81371
HTTP/1.1 200 OK
{
    "body_html": "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.0 Transitional//EN\" \"http://www.w3.org/TR/REC-html40/loose.dtd\">\n<html><body>\n<p>The other day I was touching up a PR that had been approved and was about to merge and deploy it when, out of habit, I checked the clock. It was 3:45pm, which for me, was past my \"merge before\" time of 3:30pm. I decided to hold off and wait until the next morning. </p>\n\n<p>The whole process got me thinking. Does anyone else have their own personal merge or deploy policies? Is there a time before or after when you say, not today? Is there a day of the week you don't like to merge stuff. A lot of people joke about read-only Fridays, but I have to admit, I kinda follow that rule. Anything remotely high risk I wait until Monday to merge. </p>\n\n<p>What's your personal merge/deploy policy?</p>\n\n</body></html>\n",
    "canonical_url": "https://dev.to/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "comments_count": 6,
    "cover_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--o6RV_02d--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/oqg9vv4u2c5orc3y2n6n.png",
    "description": "What's your personal merge/deploy policy?",
    "id": 81371,
    "ltag_script": [],
    "ltag_style": [],
    "path": "/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "positive_reactions_count": 13,
    "published_at": "2019-03-22T22:19:36.651Z",
    "readable_publish_date": "Mar 22",
    "slug": "whats-your-personal-mergedeploy-policy-30mi",
    "social_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--MJYBx9D---/c_imagga_scale,f_auto,fl_progressive,h_500,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/oqg9vv4u2c5orc3y2n6n.png",
    "tag_list": "discuss",
    "title": "What's your personal merge/deploy policy?",
    "type_of": "article",
    "url": "https://dev.to/molly_struve/whats-your-personal-mergedeploy-policy-30mi",
    "user": {
        "github_username": "mstruve",
        "name": "Molly Struve",
        "profile_image": "https://res.cloudinary.com/practicaldev/image/fetch/s--UrIkLrxe--/c_fill,f_auto,fl_progressive,h_640,q_auto,w_640/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/119473/9e74ee0e-f472-4c33-bfb4-79937e51f766.jpg",
        "profile_image_90": "https://res.cloudinary.com/practicaldev/image/fetch/s--apWeHy1C--/c_fill,f_auto,fl_progressive,h_90,q_auto,w_90/https://thepracticaldev.s3.amazonaws.com/uploads/user/profile_image/119473/9e74ee0e-f472-4c33-bfb4-79937e51f766.jpg",
        "twitter_username": "molly_struve",
        "username": "molly_struve",
        "website_url": "https://www.mollystruve.com"
    }
}
Enter fullscreen mode Exit fullscreen mode

宾果！！

我现在只需：第一，检查文章 ID 是否连续；第二，如果第一点成立，则查找最新文章的 ID。
这两点都很容易检查。我只需要打开浏览器检查器，查看最近的文章几次即可。

接下来，我用 scrappy 调用了这个 API 94k 次，并将信息存储在一个明文中.csv。更多这方面的内容，以后再发帖讨论。

为此，我使用了 ScrapingBee，这是我最近推出的一款网络抓取工具😎。

我们现在有什么？

在 94k 次 API 调用中，几乎有一半返回了404: resource not found。我猜这意味着创建的文章中有一半从未发布过，但我对此并不确定。我仍然有大约 40k 个数据点，这足以证明我的观点。

我的 csv 文件中的每一行都包含许多有用的信息，但对于我想要的内容，我只需要两样东西：点赞数量和发布日期。
希望 API 能够返回这两个信息，参见positive_reaction_count前面published_at代码片段中的 。

丰富数据

为了处理数据，我使用了 pandas，这是一个著名的 Python 库，它甚至是GitHub 上最著名的 Python 包之一。

我将在这里展示一些代码片段，如果您想要更详细的教程，请在评论中告诉我。

使用 Pandas 从 CSV 加载数据非常简单：

import pandas as pd
df = pd.read_csv('./output.csv')
Enter fullscreen mode Exit fullscreen mode

因为我想知道在 dev.to 上发布帖子的最佳时间/日期，所以我需要将该published_at列转换为另外 2 列：（day_of_week'星期一'、'星期二'，...）和hour。

Pandas 可以轻松添加、转换和操作数据。我只需要几行代码：


df['hour'] = pd.to_datetime(df['published_at']).dt.hour

days_arr = ["Mon","Tue", "Wed", "Thu", "Fri", "Sat", "Sun"]

def get_day_of_week(x):
    date = pd.to_datetime(x)
    return days_arr[date.weekday()]

df['day_of_week'] = df['published_at'].apply(get_day_of_week)
Enter fullscreen mode Exit fullscreen mode

我所有的数据现在都存储在一个数据框中，主要数据结构使用了我的熊猫，因此得名：df。

有点数据可视化

我现在已经掌握了我需要的所有信息。

这是我的数据框中的内容：

星期几 小时 积极反应计数
星期四 0 4
星期一 1 三十四
... ...  ...
太阳 22 41
星期四 17 9

每一行代表一篇帖子，大约有 38k 行。

我接下来自然而然地会positive_reaction_count按天和小时进行汇总。

以下是在 Pandas 中执行的操作：


aggregated_df = df.groupby(['day_of_week', 'hour'])['positive_reaction_count'].sum()
Enter fullscreen mode Exit fullscreen mode

现在我的 df 看起来像这样：

天 小时 积极反应计数
周一 0 4110
1 3423
2 2791
... ...  ...
22 4839
23 3614
... ...  ...
星期日 0 110
1 423
2 731
... ...  ...
22 4123
23 2791

太好了，为了得到我需要的格式的数据，还需要做一些工作。
基本上就是旋转列。


pivoted_df = aggregated_df.reset_index().pivot('hour', 'day_of_week', 'positive_reaction_count')
Enter fullscreen mode Exit fullscreen mode

现在我的 df 看起来是这样的：

小时 星期一 星期二 ... 太阳
0 4110 5071 ... 5208
1 3423 4336 ... 3230
2 2791 3056 ... 1882
... ... ... ... ...
23 3614 4574 ... 3149

现在，我终于可以使用该seaborn包来显示漂亮的热图了。

import seaborn as sns
sns.heatmap(pivoted_sorted , cmap="coolwarm")
Enter fullscreen mode Exit fullscreen mode

以下是我得到的结果：

分析

我觉得这张热图非常简单易懂。地图上有两个区域非常醒目：左下方的红色区域和右上角的深蓝色区域。

但首先，因为我们讨论的是时间，所以我们需要知道我们讨论的是哪个时区。
如果你仔细查看published_at": "2019-03-22T22:19:36.651Z，你会注意到Z时间字符串末尾有一个 。
这Z表示该时间字符串代表的是 UTC 时间，或者说是 ero 时区Z。

回到我们的热图，我们注意到周一到周三下午（对于东海岸的人来说是周一和周三上午）是地图上最活跃的区域。
周六和周日是两天非常平静的日子，尤其是从午夜到中午。

所以，乍一看，你可能会觉得最好多发些帖子，这样才能最大限度地提高获得点赞的几率。好吧，我们需要稍微退一步来看。

这张热图显示的是一天中点赞数最多的时间。它没有考虑到帖子越多点赞就越多这一事实。

所以也许，现在我们还不能确定，我们在热图上看到的红色区域只是意味着我们在平台上观察到更多类似的东西，因为在那些时间发布了更多文章。

这种差异至关重要，因为我们想知道的是发布帖子的最佳时间，以便最大限度地获得点赞，而这张地图无法帮助我们。

所以我们需要制作同样的地图，但不是计算每天一个小时内的点赞总数，而是计算这些点赞数的平均值。
我们也可以计算中位数，我就是这么做的，结果差别不大🙂。

感谢 Pandas，我们只需要在代码中改变一小点：


# sum -> mean
aggregated_df = df.groupby(['day_of_week', 'hour'])['positive_reaction_count'].mean()
Enter fullscreen mode Exit fullscreen mode

这是新的热图：

如您所见，这张热图与之前的图有很大不同，而且更具可利用性。
我们现在观察到了条带状模式。其中一条宽阔的蓝色区域横跨周一至周日凌晨 4 点至上午 10 点。
我们还观察到 UTC 下午的活动高峰。

根据该热图，我们现在可以得出这样的结论：
下午发布的文章平均比 UTC 时间凌晨发布的文章多出 10 到 20 个积极互动。

我认为这完全取决于读者/作者的比例。这两张热图显示，周末的读者数量虽然少得多，但作者的数量也相应减少。这就是为什么周末发布的文章与周中发布的文章互动量相同。

感谢您阅读：

我希望你喜欢这篇文章。

这个系列还远未结束，我还有很多与该数据集相关的信息可以向您展示。

如果您想分析 dev.to 数据的某个特定方面，请在评论中告诉我们，并且不要忘记订阅我的时事通讯，我会提供更多内容（您还可以免费获得我的下一本电子书的第一章😎）。

如果您想继续阅读一些 Python 技巧，请访问那里，您可能会喜欢它:)。

如果您喜欢 JS，我发布了一些您可能会喜欢的东西。

如果您更喜欢 git，我可以为您提供帮助。

文章来源：https://dev.to/daolf/-what-is-the-best-time-to-post-on-devto-a-data-backed-answer--1kob
Devto 翻译
PREV
有史以来最受推荐的 25 本编程书籍。
NEXT
React 初学者问答帖 ⚛