#1651: スプレッドシートのデータで先行ゼロに対処、ckbk から広告追跡を取り除く

この規模と標的視聴者と目玉の匿名時代にあっても、個人的なやり取りにはやはり価値があるものだ。先月、私は Matthew Cockerill からメールを受け取った。彼は、多くの TidBITS 読者が初めて私に手紙をくれる時の様に自己紹介してくれた。

90 年代初期の Mac 使いの博士課程の学生として 30 年前に TidBITS をフォローし始めた者として、"私は料理本が好きだ" で始まる最新の記事の一つを見るのはとても心地良かった。🙂

Matt は "料理本をデジタイズするのに Live Text を使おう" (5 January 2023) を指していて、彼のサービス ckbk を私に知って欲しいと思った。ckbk は定期購読者に対して約 700 の料理本の全文を提供している。私は Jeff Carlson もこの会話に巻き込んだ。彼は我々のために "料理用 Web サイト Eat Your Books" (17 March 2022) を書いてくれていた。そして、全てが順調に行けば、我々はこの話題に関するもう一つの記事を一ヶ月かそこらで出せると思う。(私のメールをさっと検索してみたら、Matt と私は二人とも、同じ出版界のメーリングリストに参加していることが分かった。そこで私が知ったのは、彼は分子生物学で博士号を取った後、アクセス自由な科学出版社 BioMed Central を共同設立し、そしてデザインとイノベーションのコンサルト業を営んでいる。)

しかし、それが私が今日書こうとしていることではない。Matt のメールを受け取った後、私は ckbk アプリを iPhone にダウンロードしたのだが、対面でも楽しい時間を持てそうな誰かからの、この人を惹きつけて止まなそうなサービスが、私を追跡したいと欲しているように見えることを発見して落胆した。

このダイアログを見る度に、私は直ぐにその会社と製品に疑念を抱き、常に Ask App Not to Track をタップ、そして同時に小声で野卑な言葉を呟いてしまう。私はそれからそのアプリのスクリーンショットを撮った。こうすることで、いかがわしいビジネスモデルと不安を感じさせる行動規範を持つのはどの会社かを簡単に記録出来、Photos で画像テキスト "Ask App Not to Track" で検索して引っ張り出せる。(全リストは Settings > Privacy & Security >Tracking にある。)

私は、Matt のメッセージに対して、このサービスについての質問をつけて返信し、そしてそのアプリが私を追跡する承諾を求めていることに対する私の失望も伝えた。彼からの返事：

アプリが "追跡" を求めるという事実に関して言えば - あなたの立ち位置は私にも分かるが、それは聞こえるほど悪意に満ちたものではない... "追跡" がオンにされていなければ、アプリやアプリストアは最も基本的な情報すら提供出来ない - 例を挙げれば、我々の販売促進のための支出或いは提携先のどれがユーザーを ckbk アプリにもたらしたのかや、単なるお金の無駄遣いだったのはどれかかを知る術はない。我々の販売促進の効果の基本的な尺度を持つためには、追跡をお願いする以外の選択肢は無いように思える。これとより広範な種類のサードパーティ追跡との間に Apple によって設定された違いが無いのは残念である。

これで私の気分は幾分か和らいだ。本格的な追跡を許すには十分ではないが、広告や提携先から行動迄のクリックスルーを合致させる必要性は理解出来る。我々も顧客が何処から来たのかを知るためにそれを Take Control Books で四六時中やっているが、やっているのはそれだけだ。しかし、Matt の次のメールは私の気分をもっと良くしてくれた：

実際、この件についてのご理解に感謝する - 私は更に色々調べていたらこれは急速に動いている空間である事が分かった。そして、我々側から追跡を頼んだり、或いはユーザー側でのオプトインを必ずしも必要としないでダウンロードを追跡出来る新しいプライバシー保護方法がある。そこで、我々はこの件に関しても少し手を入れて、新ユーザーに不快感を引き起こす "追跡" リクエストを出さないで済むようにしたいと思っている...

２週間後、それは実行された：

ちょっと伝えておこうと思いまして、我々はあなたのフィードバックを受け入れ、ckbk アプリから "追跡" を取り除くことが出来た。(実際、我々はもう既に追跡をしていなかったが、メタデータをアップデートし、追跡がフラッグされるようにしているライブラリを除去する必要があった。)

これは思ったよりも *遙かに* 難しいことだった。と言うのも、 重要な App Store バグがある様で、その結果 Catch-22 (どうもがいても解決策が見つからないジレンマ) があり、Apple は最早追跡しなくなったアプリを拒絶することになってしまう。その理由は '対応するメタデータが無い' からであり、そして新しいアプリがライブになる迄それを対応させる方法はないからである。Catch-22 状況を作り出してしまう。その解決方法は App Store への不服申し立てしかない。しかし、我々はそこを何とか切り抜けられた...

これは個人的なつながりを作ることの証しである。Matt の極めて適切な紹介は、我々も ckbk について書くことになるであろうことを意味し、そして私の失礼にならないよう表現した追跡に対する失望も ckbk のアプリの内部に手を入れてそのダイアログを取り除く結果につながり、これは新しい ckbk ユーザー、TidBITS 読者も含めて、に対してはより良いユーザー体験を作り出すことになるであろう。皆が勝者となる。

私はまた Apple の App Tracking Transparency が以前思っていたよりも少々鈍器以上のものなのかも知れないことを学んだ。上記のスクリーンショットにも見られる通り、私は未だに追跡したいと頼んできたアプリを結構多く使っている。それ等は私が以前信じていた程には邪悪では無いのかもしれないが、それでも私はそれ等に許可を与える積もりはない。そして、どうか Facebook や Instagram の様なものについて私に話させないで欲しい。私の iPhone にその類いのものを近づける気は一切ないのだから。

討論に参加

昔風と言われるかもしれないが、Tonya と私は今でも郵便でホリデーカードを家族や友人に送って、過ぎた一年を振り返るようにしている。その作業は必ずしも毎年 12 月中に間に合わせているとは限らず、ここ数年はそれが遅れに遅れて実際にはバレンタインデーのカードを装いつつ 2 月中旬に新年の振り返りを出すようになってしまっている。面白いことに、遅くにカードを出すことによって、むしろ友人たちとの会話が以前より多くなった気がする。なぜなら、クリスマスカードや新年のカードよりもバレンタインデーのカードの方が少ないので目立つからだ。

でも、今は 3 月中旬だというのに、いったいなぜ私はこんな話をしているのだろうか？ それは、私たちが投函した束の中の 1 通が、2 か月経った今になって返送されてきたからだ。返送にそんなに長い時間がかかったことにも驚いたが、自分たちが宛先の住所を間違えていたことの方がショックだった。カードを数分間見つめるだけで何が問題だったのかが分かった。そのうちに光明が見え始めた。

米国北東部の多くの州で、ZIP コード (郵便番号) が 0 で始まる。コネティカット、メーン、マサチューセッツ、ニューハンプシャー、ニュージャージー、ニューヨーク、ロードアイランド、バーモントにそういうものがあるし、それ以外にもプエルトリコや、軍施設や海外施設用の APO/FPO European 特別配達用コードも 0 で始まる。今年はカードの宛先ラベルの作り方でちょっとした夫婦喧嘩をした結果、Tonya がその作業を担って去年までの私のやり方とは違う作業をすることになった。私は Contacts から Belight Software の Swift Publisher に接続していたのだが、彼女は Avery Design & Print Online ツールを使うことにした。住所データを Contacts から Avery のウェブアプリへ持ち込むために、Tonya はそれを Excel (XLS か XLSX) または CSV (テキストのみのコンマ区切り値) のいずれかのフォーマットにする必要があった。残念なことに Contacts アプリは CSV への書き出しができず、書き出せるのは VCF (vCard という名前でも知られる) または独自の ABBU フォーマット (このアプリは Contacts アーカイブと呼んでいる) のいずれかのみだ。

Tonya は Contacts からデータを転送するために、まず Holiday Cards グループにあるすべてのカードを選択してから、それを Numbers の空白のシートの上へドラッグした。Numbers 上でデータを望みのフォーマットに変換する方法を知らなかったので、それを Microsoft Word の中へコピーした。彼女は 1990 年代初期の数年間 Microsoft 社で Word のサポート担当の仕事をしていたので、Word は彼女にとってほとんど何にでも使えて頼りになるツールであった。それを私が批判することはできない。ちなみに私のデフォルトのツールは BBEdit と grep だ。

どうやら問題が起こったのは、彼女がデータを Word から Excel に移して、Avery が受け付けるファイルに書き出したところにあったらしい。デフォルトで、Excel はペースト/読み込みされたデータのカラムを General にフォーマットするようで、これは数値フォーマットだ。数値フォーマットにおいて先行ゼロは意味を成さないので (Mr. Bond にはお気の毒だが 007 は 7 と同じなので) Excel は何のためらいもなくそれを削除し、5 桁の ZIP コードがたった 4 桁の誤ったコードに変わってしまう。(ZIP コードが 3 桁になってしまうこともある。例えばニューヨーク州 Holtsville のコードは 00501 だ！) 後から ZIP コードのカラムを Text に戻そうとしても役に立たない。なぜなら、Excel はテキストを数値として読み込んで、保存された値を数値に変換するだけだからだ。Apple の Numbers アプリも、ほとんどのデータを (Contacts からコピーしたりドラッグしたりしたものを除いて) 同様のやり方で扱う。(この記事の最初の版を出した後に貴重な情報を教えてくれた Alan Forkosh に感謝したい。彼によれば、Excel は実際 ZIP Code というフォーマットを備えていて、それは奥深くの Format > Cells > Number > Special に隠されている。このフォーマットに切り替えておけば問題は解決したはずだ。)

Contacts に正しく ZIP コードを入力してあったことには確信があったし、友人たちの ZIP コードを覚えている訳ではなかったので、宛先ラベルを印刷する最中に ZIP が 4 桁になっていることに気付かなかった。いったい誰が ZIP を注意深く見たりするだろうか？ さらに悪いことに、最初に返送されてきた 2 枚のカードについては原因を知るためによく見ることすらしなかった。Paul と Andy には申し訳ないことをした！ (興味深いことに、私たちが 4 桁の ZIP コードで出したカードはまだすべてが返送された訳ではない。もっと遅れて返送されるものもあるかもしれないし、どこかの郵便局か郵便スキャナが私たちのミスを回避して送り届けてくれたかもしれない。印刷された宛先と、手書きの宛先の大多数は、完全に自動的に処理されているのだ。)

だから、米国の住所や、または UPC や SKU の番号など、先行ゼロを含む可能性のあるデータをスプレッドシートに入れる場合には、先行ゼロが欠落していないかどうかを確認しておくべきだろう。私はいろいろ実験してみて、データを Contacts から取り出す際に ZIP コードの先行ゼロを維持できるやり方を 2 通り見つけたので、以下で紹介しよう。他の種類のデータについても対処のためのコツを少し書き添えておきたい。

Contacts > Numbers > CSV

すべてが Apple エコシステムの中にある場合には、データを Contacts から Numbers へドラッグしたりコピー＆ペーストしたりする限りすべてが持ち込まれ、ZIP コードの先行ゼロもそのまま保たれる。なので次のようにすればよい：

1. Contacts でカードを送りたい人々を選択する。その人たちを同じグループにまとめてあるならばとても簡単だ。その場合は Command-A を使えばよい。
2. Command-C を押してそれをコピーする。
3. Numbers に切り替えて、新規の空白のスプレッドシートを作成し、それから Command-V を押してペーストする。

言い換えれば、ほんの数回クリックしたりキーを押したりするだけで済む。その後、不必要なカラムを削除したり、データに編集を加えたりしてから、CSV に書き出す。

もっと別の情報源から先行ゼロを含むデータを Numbers に持ち込もうとする場合には話が複雑になる。その場合には、どうやら 最も良い解決法はデータを二重引用符で囲ってからその直前に等号を入れることのようだ。つまり、もし ZIP コードが 07470 ならば、まずその情報源のデータを ="07470" に変えてから、それを Numbers で開くのだ。(以前は一重引用符で囲うようにと言われていたこともあるが、どうやらそれはうまく動作しなくなっているようだ。)

そのような ZIP コードがずらりとカラムに並んだものを CSV に書き出す方法は読者への演習問題としておこう。もちろん、BBEdit や Nisus Writer Pro のような grep 対応のエディタがあれば簡単で、単に ,([0-9\-]{5,10}), を検索してそれを ,="\1", に置き換えればよいだけだ。

Contacts > VCF > CSV > Excel > CSV

Mac ユーザーなら誰でも、Contacts からコピーして Numbers へペーストすることができるはずだ。Numbers は Mac App Store から無料でダウンロードできる。けれどもここでは議論の目的上、Numbers を使わずに Contacts から Excel に移す必要があると仮定しておくことにしよう。幸いにも、VCF ファイルに書き出してからそれを CSV に変換するのは簡単だ。

1. Contacts でカードを送りたい人々を選択する。
2. File > Export > Export vCard を選び、ファイルをどこかに保存する。
3. vCard to LDIF/CSV Converter ウェブサイトにナビゲートして、Choose File をクリックし、さきほどのファイルを選ぶ。
4. Format メニューで CSV を選び、Convert をクリックする。変換されたファイルは自動的にダウンロードされる。
   

住所あるいはその他のデータの入った CSV ファイルが手に入ってそれを読み込めるようになれば、Excel で以下の手順を辿れば先行ゼロを失うことなく開くことができる：

1. Excel で新規ファイルを作成する。
2. File > Import を選ぶ。
3. Import ダイアログで CSV file を選び、Import をクリックする。
   
4. そこで開いた Open ダイアログでさきほどのファイルを選ぶ。
5. Text Import Wizard の Step 1 で、Delimited が選ばれていることを確認して、Next をクリックする。
   
6. ウィザードの Step 2 で、Tab を非選択にし、Comma を選択する。すると、データがカラム状にきちんと整列するのが見える。Next をクリックする。
   
7. ウィザードの Step 3 が重要だ。最初のカラムが (黒く) 選択されている状態で、水平方向に (２本指で) スワイプまたはスクロールして、一番右のカラムに達するまで進む。(スクロールホイールの場合には Shift キーを押し続けたままで水平方向にスクロールする。) それからそのカラムを Shift-クリックすることで、途中にあるカラムもすべて選択して、全部が黒い状態になる。
   
8. Text ラジオボタンをクリックして、カラムのヘッダが General から Text に変わったことを確かめる。Finish をクリックする。
9. 最後の Import Data ダイアログで、データの保存先を選んで、Import をクリックする。
   

将来このファイルを使って作業する可能性があると思えば、CSV でなく XLSX フォーマットで保存しておく。CSV はテキストフォーマットであってフォーマッティングの情報を含んでおらず、あとで Text Import Wizard を使わずに Excel に読み込ませれば先行ゼロが失われてしまうからだ。

ちなみに、さきほど述べた先行ゼロを含むデータを二重引用符で囲って前に等号を付けるテクニックが Excel でも使えることを注意しておこう。

Excel が 35 年、Numbers が 16 年という長い年月を経てさえ、どちらもまだ読み込んだ先行ゼロの処理のために余計な作業が必要だというのは、とても恥ずかしいことだと思う。ファイルが先行ゼロを含むことを探知すればユーザーに対してそれを維持するか否か尋ねるのが、そんなに難しいことだろうか？ Google Sheets でさえ、Import ダイアログの中にそのための単純なチェックボックスを提供している。チェックを外しておくだけで、ZIP コードが完璧に読み込まれる。

当然ながら、もしも Contacts アプリにもう少しまともな宛先ラベル印刷機能が備わりさえすれば、この記事に書いたことはすべて不必要になることだろう。ただしその際には、宛名を連名にしたカードを Miss Manners にも認めてもらえる程度に適切な方法で扱うためのフォーマッティングのオプションを 2 つ、ぜひとも提供して欲しいものだ：

• 宛名の二人が同じ名字を持つ場合、ラベルの最初の行は First & Spouse の形式であるべきだ。例えば、私の名前 Adam を私の連絡先カードの first name フィールドから取り、Tonya Engst をそのカードの Spouse フィールドから取って Adam & Tonya Engst という行に仕上げるべきだ。
• 二人の名字が異なる場合、ラベルの最初の行は First Last & Spouse という形式になるべきだ。もしも Tonya が今でも旧姓を使っていたと仮定すれば、ラベルは Adam Engst & Tonya Byard となるだろう。

いずれの場合でも、Spouse フィールドには配偶者のフルネームを入れておく必要がある。

Swift Publisher にはそれができるのだが、Swift Publisher と Contacts との間の接続は頼りにならないことがある。それ以外のアプリで Contacts から取り込んだデータにこの種のフォーマッティングのオプションを提供できるものを私は知らないが、もしご存知の方がおられればどうぞコメントで知らせて頂きたい！

討論に参加