使用 Airtable 建立自己的数据收集模式

如今,数据已经被称之为信息时代的「黄金」,个人可以通过数据来量化自我,公司可以使用数据来帮助决策。互联网服务商可以通过收集用户数据提供更加个性化的服务,我们也可以收集自己的数据来优化自己的生活方式。

近一年来,我开始意识到自己作为数据发生器的重要性,于是就开始下意识地集中收集自己产生的各类数据,建立自己的数据收集模式。而谈到为什么要集中收集个人数据,主要原因应该有两点:

  1. 目前使用了 MovesRescueTimeToggl 等各类应用来收集自己的地理位置、时间消耗等数据。但是这些数据都储存于单独的应用之上,过于分散。
  2. 自己看得见,摸得着的数据,比放在别人的服务器上更放心,也更容易集中加以利用。

集中收集数据,意味着 Moves,RescueTime 等应用变成了纯粹的收集工具,而数据会汇总到自己手中。不同类型的数据一旦汇集到一起,不仅可以针对单一类别数据进行可视化展示,还能分析出数据直接的关联性,对自己的行为更具有指导意义。

选择一款云端表格工具

数据收集的末端,对应着用于存储数据的数据库。当然,对于个人数据收集而言,我们常说的电子表格其实就足够了。最让大众熟知的电子表格工具一定是 Microsoft Excel 。但是,作为一款桌面软件,Excel 往往并不适用于现代的数据收集流程。例如,你想将你的微博存档保留,难道是通过手动复制粘贴到 Excel 文档中吗?显然不太实际。

所以,如果我们有一个放在云端的电子表格,可想象的空间就大很多了。说到云端电子表格,不得不再次提到 Excel,只不过这次是它的孪生兄弟 Excel Online,作为 Office 365 的套件之一,Excel Online 除了无法处理宏命令,其他方面几乎就是桌面版 Excel 的完美克隆。

相比之下,本文的主角 Airtable 的名气就远不及 Excel 了。但是,作为一个典型的硅谷公司产品,Airtable 也拥有不错的口碑。此外,Google Sheets 也是优秀的云端表格工具,只是这朵云离我们稍微远了一些。

那么,对于这三款相对优秀的云端电子表格,到底哪一款更加适合用于个人数据收集整理呢?我做了一个对比。

当我选择的时候,最看重的功能其实是 API 支持。只有具备了 API 接口,才能让数据收集流程可以实现自动化,也才是名副其实的「云端表格」。而让我最终选择 Airtable 的原因,应该有如下几点:

  1. 基础功能同另外的两个产品相比没有明显的缺失,甚至拥有像条码输入、iframe 嵌入等更多差异化功能。
  2. Airtable 同时支持 IFTTT 和 Zapier 云端自动化工具,且 API 使用起来更简单方便。很多时候,就算使用现有工具无法满足需求,也可以根据开发者文档自行编写代码实现数据读取和写入。
  3. Airtable 外观设计更加漂亮,这一点在长时间的使用过程中非常重要。

Airtable 使用简介

在正式介绍我是如何使用 Airitable 集中整理数据之前,我想先对 Airtable 做一个简单介绍。

如下图所示,Airtable 主要包含有 6 个基本组件,分别是:

  • Bases(数据库):Airtable 数据储存组成单元,你可以在用户主界面创建不同的数据库。
  • Tables(数据表):Bases 数据库的组成单元,一个数据库中可以创建多个数据表,且同一个数据库中的数据表之间可以形成数据关联。
  • Views(视图):Tables 的不同展示方式,默认为表格,还有日历、表单等额外的 4 种样式。视图使得展示效果更加丰富,一个写满日程的数据表,显然使用日历视图更加直观。
  • Fields(字段):Tables 中的列属性,与常见的电子表格不一样的地方在于,Airtable 的字段可包含像条形码、评分、复选框、附件等更个性化的格式。
  • Records(记录):Tables 中的行属性,也就是数据表中的数据。
  • Blocks(模块):Beta 功能,提供像数据概览、数据可视化、计时器、发送短信等拓展模块。模块功能目前仍然在内测过程中,仅 Pro 版的付费用户可以申请使用。

可以看出,Airtable 从诞生之初就具备了关系型数据库的样子,已经满足了对数据储存的日常需求。从功能上,除了 Excel Online,基本上没有竞品。

要想对个人数据进行集中收集整理,首先需要在 Airtable 创建不同的数据库。建立数据库是个人数据收集工程中的第一步,所以并不是随意乱建的。其中,我们需要先想一想收集数据的大类,然后在细分大类中的小类,并对应到数据表中。我的数据库主要有下面 3 个,树形结构如图所示。

工作学习数据库

工作学习数据库会收集平常我在工作或者学习中产生的相关数据。根据我的使用习惯,数据库包含了 4 张数据表,分别是:Calendar、Todoist、Trello 以及 Issues(同步 Github)。看到名字应该就很容易明白这 4 张表的意思了。

对于这四类服务的数据,我均是采用 IFTTT 或者 Zapier 将其同步到 Airtable 中。这里补充介绍一下 IFTTT 和 Zapier 的区别与联系。首先,二者都是整合不同应用提供的开发者 API 实现自动化流程的云端服务,这是他们的相同之处。但是,Zapier 相对于 IFTTT 会更强大一些,它一般情况下会支持原服务更全面的 API 接口,且支持多个服务联动。相比之下,IFTTT 很多时候只提供主要的接口,且只支持两个服务之间的数据传递。

举个例子,当我在使用 Zapier 实现 Google Calendar → Airtable 的过程中,Zapier 支持读取 Google Calendar 中的 43 项数据(虽然有一些不实用),但 IFTTT 只支持 8 个。当然,IFTTT 也有比 Zapier 好用的时候。比如将 Todoist 完成任务同步到 Airtable 时,Zapier 不支持监测任意 Project 下完成的任务,需针对每个 Project 设置单独的流程。

四个服务同步到 Airtable 的设置都大同小异,这里我只拿 Todoist → Airtable 详细说明。当我选择 IFTTT 作为 Todoist → Airtable 的同步工具时,首先需要到 IFTTT 上看一看其支持读取 Todoist 的哪些数据,你可以通过创建动作时查看。

我们可以看到从 Todoist → Airtable 一共支持 7 个类别的数据。那么,现在可以先新建这个动作。注意,你需要遵守 IFTTT 制定的语法格式,才能正确地将数据写入到 Airtable 中。

也就是说,如果要将这 7 类数据全部同步到 Airtable,你需要在 IFTTT 动作的最后输入如下所示的内容。我习惯之间使用 IFTTT 的 ingredient 名称作为 Airtable 中的列名称。

格式:::airtable::Airtable 中的列名::{{IFTTT 中的 ingredient}}

示例内容:

::airtable::TaskContent::{{TaskContent}}
::airtable::LinkToTask::{{LinkToTask}}
::airtable::Project::{{Project}}
::airtable::Labels::{{Labels}}
::airtable::Priority:: {{Priority}}
::airtable::CompletedAt::{{CompletedAt}}
::airtable::DueDate::{{DueDate}}

接下来,就可以到 Airtable 中设置相应的列名称了。在设置对应的列属性(文本、数字、图片等)时,我建议一开始统一设置为「Single line text」,也就是单行文本格式,以防止导入数据出错。

当测试导入成功之后,就可以调整列属性。例如这里,Project 的数量是有限的,且每个任务只对应一个 Project。就可以将其列属性设定为 Single select(单选),这样也方便日后对任务进行筛选。同样,日期可以使用 Date 属性,链接使用 URL 等。

如果调整列属性之后,表格显示为空白或报错,那就意味着通过 IFTTT 传过来的数据格式并不能很好地被 Airtable 支持。比如这里的 CompletedAt,也就是项目的完成日期 + 时间。IFTTT 输出的数据格式是像这样的 January 20, 2018 at 10:18AM,Airtable 无法之间将其转换为对应的「日期+时间」的格式。

为了方便之后的数据分析,我们其实更偏向于将其处理成时间序列,也就是按 Airtable 中的「日期+时间」格式保存。此时,我们可以通过新建中间列作为过渡,然后利用 Airtable 的 Formula 公式将原文本列转换为可识别的「日期+时间」列。具体步骤如下:

  1. 明确区别: 原文本列格式为January 20, 2018 at 10:18AM,Airtable 可识别的格式为January 20, 2018 10:18 AM。注意观察二者之间的区别,文本格式多了 at + 一个空格 字符,同时 AM 字符前缺少一个空格。
  2. 格式转换:明白区别之后就可以开始使用 Airtable 提供的 Formula 公式转换格式。首先是去掉 at 字符,然后在结尾的 AM 或者 PM 前面增加空格。

这里使用了 SEARCH() 函数去定位要修改的位置,然后使用 REPLACE() 函数修改字符。最后再使用 DATATIME_FOMRMAT() 函数格式化字符串为我们想要的「日期-时间」样式。一个小的技巧是,如果你嫌增加的中间列较多,那么可以使用 Airtable 顶部菜单的 Hide fields 选项隐去不必要的列,只呈现我们需要的数据即可。

量化自我数据库

我的第二个主要数据库为量化自我数据库,它是由:Moves、Location、Apple Health、RescueTime 以及 Commute 等 5 个数据表组成。这 5 个数据表分别对应着 Moves 记录的地理位置数据、手动签到数据、Apple Health 记录的运动健康数据、RescueTime 记录的工作效率数据以及通勤时间统计数据。

Moves 数据

提醒:Facebook 已于 2018 年 6 月 31 日正式关闭了 Moves 服务,推荐使用 Gyroscope 替代。

Moves 是我一直在使用的地理位置追踪应用,它的运动状态识别和地点识别做的非常好,以至于现在都没有找到可替代的应用。Moves 其实拥有完善的 API,但由于其认证方式的特殊性,IFTTT 和 Zapier 都尚未支持与 Moves 连接。于是,我只能自己编写一个 Moves → Airtable 的脚本,然后部署在云服务器上,每天自动将昨天产生的数据同步的 Airtable 中去。

实现的过程比较麻烦,都能凑够一篇文章了,另找时间再细说。这里,Moves 的数据包含有经纬度信息,你可以直接使用 Airtable 提供的 Map Block 模块对地理位置可视化。

关于 Airtable Blocks 的更多介绍,可以阅读官方的文章《Getting started with Airtable blocks

Location 数据

除了使用 Moves 自动记录地理位置信息,我还自己制作了一个辅助签到的 Workflow 用来标记我认为重要的地点,并把地理位置数据实时上传到 Airtable 中的 Location 数据表中。

Workflow 非常简单,流程如下:定位 → 解析数据 [街道 - 城市 - 地区 - 国家] → 解析数据 [经度 - 纬度 - 高度] → 结合当前时间一并上传到 Airtable 中。

Apple Health 数据

目前,追踪健康信息主要是使用 Apple Watch 和 iPhone,通过本身的健康应用以及配合 Moves,Autosleep 等第三方应用完成。Apple Health 无法实现 iCloud 同步,更没有 API 支持,所以只能半自动同步到 Airtable。我采用的方法是定期从 Apple Health 中导出数据文件到 Dropbox 中,Dropbox 的数据压缩包会自动同步到云服务器中,再由云服务器中部署的 Python 脚本自动完成数据解析,并通过 API 同步到 Airtable 的表格中去。

RescueTime 数据

工作效率记录我会使用到 RescueTime 应用,RescueTime 会自动记录各类程序的前台运行时间,再和数据库进行比对得到相应应用属于效率应用还是非效率应用,从而自动统计每天的工作效率。

RescueTime 的数据同步到 Airtable 就比较方便了,可以使用 IFTTT,Zapier 或者开发者接口同步。我选择的是 Zapier,因为它可以同步多达 59 项数据信息。触发的动作选择「当每日数据汇总后」,然后再将对应的数据更新到对应的列即可。过程非常简单,就不再赘述了。

这里介绍一个使用 RescueTime 的一个小技巧,那就是最好定期去手动标记相应应用的效率属性。首先,我们每天浏览的大多数网页或者使用的应用都是比较固定的,手动标记花费的时间不多。其次,有一些应用对每个人的效率属性不一致。比如,我已经好多年没用 QQ 作为和别人的聊天工具了,所以凡是当使用 QQ 时,基本上都属于处理工作上面的事情,它对于我而言就是效率状态,而不是消遣状态。

通勤时间数据

Commute 表用来统计我的通勤时间。每天,我都会选择地铁作为上班通勤的主要交通工具,虽然地铁在站与站之间的运行时间比较确定,但由于存在换乘,所以每天的通勤时间的变化就比较大了。打个比方,有时候早上只晚出发 5 分钟,如果正好赶上一波高峰,实际到达公司的时间往往会晚 20 分钟。所以,我从年初就开始每天记录自己的通勤时间,打算等到数据累计到一定量之后,通过数据分析得到自己每天的合理出发时间。

在记录通勤时间的时候,由于准备将数据保存到 Airtable,所以一开始就直接就排除了现有的计时器或者第三方 App,然后把目标集中到 Workflow。但是,很快我就发现 Workflow 的现有动作中,并没有支持在后台完成计时的动作。后来,我就想到了直接借助 Airtable 来完成这个功能,这个功能的逻辑非常简单。流程如下:

  1. 每天从家中出发的时候,点击 workflow 将此刻的时间上传到 Airtable,并记为出发时间。
  2. 当到达公司时,再次点击 Workflow 将时间上传到 Airtable 。由于 Airtable 本身可以使用数据函数,就能计算出两个时间差,并直接在我第二次点击 Workflow 上传时间后,将计算好的通勤时间推送到手机上。这样,既可以实时看到记录下来的通勤时间,也不再需要二次过程将数据上传到 Airtable 中。

信息存档数据库

信息存档数据库是用来保存我认为有必要存档的互联网数据。其中,主要有三个 Tables,分别是:微博、博客以及稍后读。

我喜欢定期清空自己的微博,防止在互联网上留下过多的「🌚 历史」。但又不想丢掉自己转发过的微博,于是就有了这个微博存档表。存档微博的方法非常简单,使用 IFTTT 新建一个动作,实时将微博记录到 Airtable 中保存。

同样,我使用 Pocket 作为稍后阅读工具,也就通过创建 IFTTT 动作,将保存在 Pocket 中的文章同步存档到 Airtable 中。

除此之外,博客存档表用来备份自己在互联网上创作的内容。比如在少数派写的文章以及自己的博客文章。该表单使用了自己编写的 Python 脚本,定期将我的博客文章以及在少数派发表的文章同步保存到 Airtable 中。

其他数据库

除了上面提到的这三个主要的数据库,我还有几个自己比较喜欢的数据库,也分享一下。

票据存档数据库

票据存档的数据库主要是记录平常我认为比较重要的收据、发票、合同文件等。当然,超市购物小票这类不太重要的票据也就没必要存档了。

教育优惠统计数据库

几个月前,我在少数派写过一篇 《在校师生福利:Apple、微软、Adobe 等产品如何通过教育优惠购买》 ,这篇文章中介绍一些高校学生可以享受的教育优惠项目。不久前,我通过 Airtable 整理了一份更加详细的教育优惠表单,希望更多的学生能享受到低价有品质的服务。

你可以通过检索的方式来获取自己感兴趣的教育优惠项目。当然,我也呼吁大家来一起完善这个表单。如果有一些教育优惠项目非常好,但表单中未涉及到,欢迎直接通过下面的链接补充提交到表单中去。

菜品、餐馆统计数据库

最近,我正在完善的一个数据库来源于我生活中的一个痛点,那就是经常不知道吃什么。这个数据库中会记录下一些餐馆和菜品。我会将平常吃过感觉不错的,或者想吃的餐馆信息添加到餐馆数据表中,同时会记录一些做过或者想做的菜品。

当我自己想做菜吃的时候,我就会通过 Workflow 随机返回菜品作为灵感,而想出去吃的时候,也可以随机返回餐馆信息。目前,这个数据库和 Workflow 还没有完全做好,等完善之后,会同大家一起分享。

另外,文中提到的一些自动化数据获取的 Python 脚本,我也会整理后择时与少数派读者分享。

结语

我其实很早就知道 Airtable 了,但真正有效地利用起来也是近一年才开始的。目前,虽然 Airtable 已经帮我存下来不少的数据,但是我对它的利用程度还并不满意,今年我会继续发掘 Airtable 的「正确使用方式」。

如今,我们都知道时常需要备份自己的照片、手机、电脑,防止资料丢失。除此之外,我们同样应该重视起自己每天产生的其他数据。目前初步建立起来的数据集中收集模式只是开始。等待数据积累到一定量时,就需要着手「数据集中分析」,使其真正地能帮助自己发现某个坏习惯,提升一些效率,改变一些东西。