This is Michelle! She teaches English at a local community college and she's fucking amazing! There were so many thoughtful points she shared with me between conversations of teaching English, what the lower levels college English classes are like, how modern students are struggling with content basics, and how is all linked to both online communication and socio-economic conditions. We talked about growing up in poor neighborhoods and how those conditions shape not only our own personalities but how we see the world. She shared funny stories and some sad but meaningful ones too. I have this book idea that I've been wanting to write and she has inspired me. Some words of wisdom I'm taking away - Great writing is clear and to the point. Figure out what you need, what you want and what you're willing to sacrifice. So so good!
ThinkUp’s goal is to help people feel good about the time they spend online--to remind them it’s not wasted, or trivial, or necessarily better spent elsewhere. What we share and discuss and learn on our social networks matters, connects us, and can help us change the world in small and big ways.
That’s why it made perfect sense to add Instagram insights to ThinkUp. Maybe more than any other social network, Instagram makes you feel good. Basecamp’s Jason Fried articulates why in this essay, Look and Feel and Feel:
Every scroll through Instagram puts someone’s good day in front of me. A vacation picture, something new they got that they love, pictures of nature, pictures of people they love, places they’ve been, and stuff they want to cheer about. It’s just flat out harder to be negative when sharing a picture. This isn’t a small thing – it’s a very big deal. I feel good when I browse Instagram. That’s the feel that matters.
Instagram is your happy place. Now, ThinkUp makes it happier.
Connect your Instagram account
When you connect your Instagram account to ThinkUp, ThinkUp learns what photos and videos you post, how and when your friends responded to them, and what you've loved as you scrolled through your stream. As ThinkUp analyzes your Instagram activity, you'll get daily, weekly, and monthly insights that help you:
1. Find out who your biggest admirers are--the people who love your photos and videos the most.
2. Flash back to photos and videos you favorited and posted 1, 2, 3 years ago today, for the best kind of delightful nostalgia.
3. See your friends' profile changes (photos and bio lines) as they happen.
4. Know your most popular photo or video of the week and month, and find out when a photo or video is getting an unusual number of hearts.
5. Find out the best time of day to share your photos and videos.
Share the love
When you get an insight you want to share on Instagram--maybe to thank your biggest admirers, or look back at what you posted in years past--here’s what to do.
At the bottom of each Instagram insight, tap the link that says “Share on Instagram.”
You'll see a square, Instagram-ready image of the insight. Download it to your mobile device.
Upload it using Instagram’s mobile app.
Search your Instagram followers
When your followers outnumber the people you follow on Instagram even a little bit, it’s tough to keep track of who knows you and who you should follow back. In ThinkUp, you can search the bio lines of your Instagram followers and find out who is a pro photographer, who posts photos of healthy food, sunsets, flowers, surfers, and more. Once you connect your Instagram account, be sure to give follower search a try.
Behind the scenes
We spent a lot of time thinking about the best insights we could offer for Instagram, and how the insights ThinkUp already offers for Twitter and Facebook would work. In many cases, they didn’t.
Instagram is a very different kind of social network than Facebook or Twitter. Of course, in the most obvious way, it’s focused on photo-sharing and not text or links. There are many less obvious ways, too: especially in terms of the emotions the Instagram experience evokes, and the types of user behavior that emerge given Instagram’s product design.
We started out with a bulleted list about what we know about Instagram, compared to our experience building analytics for Twitter and Facebook. It looked something like this:
The Instagram experience revolves around visuals, not words or links or even people.
While there is a web-based interface to browse Instagram photos and videos, the core experience remains native mobile app-focused.
There’s no way to upload photos or videos to Instagram via the web, only the mobile apps.
Instagram fiercely guards the native mobile experience, and wants to prevent users from exiting it. There are no clickable links in Instagram captions or comments, only user profiles. As such, you’ll see a lot of “link in bio” or “Google [keyword]” in captions from folks who want to point users to content outside of Instagram.
Instagram videos are less like YouTube or Facebook videos and more like short moving photos, constrained to 15 seconds.
Instagram supports user tagging in-media, @mentions in comments, hashtags, and location.
While there is overlap with hashtags used on other networks -- for example, #tbt -- there are Instagram-specific hashtags, like #nofilter.
Nearly half of the text that appears on Instagram contain emoji (in captions, comments, and user profiles).
Instagram users <3 photos more than anything else, way more than they star tweets, or maybe even “like” Facebook status updates.
Reposts (the Instagram version of retweets or Facebook shares) are done, but only by users on third-party apps like Repost. Instagram does not support resharing natively.
Typical Instagram usage is very few comments on a photo or video. Default response to a photo or video is a fave/like/heart.
There’s more consumption than production of Instagram media. Typical usage is more browsing and liking than sharing.
Private Instagram accounts are very common, perhaps more common than private Twitter accounts. If someone private follows you and you don’t follow back, there’s no bio available via the Instagram API.
The world of Instagram apps is relatively limited compared to Twitter. Instagram’s own Layout (iOS & Android) and Hyperlapse (iOS-only) apps are popular. Other popular apps include Instashot (for making photos square), and Repost for resharing photos/videos from your stream.
We made a lot decisions on what insights to offer for Instagram based on that list. We focused primarily on the photos and videos you posted and liked, and wanted to offer ways to find, thank, and connect to people who share your interests and love your stuff.
ThinkUp’s Instagram contributors
ThinkUp’s Instagram plugin began as a project by one of our helpful open source contributors, Dimosthenis Nikoudis, back in December of 2013. Thanks so much to dnna for laying the groundwork for us. Since then, we added crawler smarts, stronger user privacy support, upgraded insights, and insight sharing with Instagram-ready images. Thanks so much to Adam Pash for his help creating those square insight images.
Going forward
This is only the beginning. There’s lots more interesting Instagram data worth plumbing in ThinkUp: hashtags, emoji, tagged users, location, colors, filters, text and object recognition.
If there’s an Instagram insight you’re dying to see, create one and tweet it to @thinkup to let us know.
Just five bucks a month: The evolution of ThinkUp’s billing system
I was a web developer for nearly 20 years before I ever built web pages that accept payments from customers. I'm not sure if that's a comment on my career in particular or the industry as a whole. But the day finally arrived in 2013, when we at ThinkUp decided to try something different: build a web business supported by customer subscriptions instead of advertising.
Since then, despite relying on third parties to handle all the complexities of credit card transactions, we've developed and deployed seven billing-related projects. SEVEN BILLING PROJECTS. It's March of 2015 now. That means our tiny team launched a new billing-related project every two to three months. In short, during the entire existence of our business, we've been constantly occupied by designing and building a system tangential to our actual product (albeit core to our business).
In order to assure myself that I'm not crazy for being tired of billing-related code, I'm documenting our journey so far here. Maybe it will help someone out there make decisions about their new subscription-based web product.
Project 1, October 2013: DIY Crowdfunding
Before we launched ThinkUp the hosted service, we wanted buy-in from the community. As an open source project built for the community by the community, it made sense. Given the rise of Kickstarter into the mainstream and the audience that Anil and I had through our writing and podcasting, we knew we could pull off a successful crowdfunding campaign. We also knew that ThinkUp would be a subscription service, and we wanted to start capturing recurring payments from day one. At the time, Kickstarter and other crowdfunding platforms didn't support recurring payments. (Patreon hadn't launched yet; but it wouldn't have made sense for us anyway. ThinkUp is squarely a subscription service versus arts patronage.)
We knew we'd have to write a subscription billing system anyway, so why not start with the crowdfunding campaign? Following in Kickstarter's footsteps, we decided to use Amazon Payments over more developer-friendly options like Stripe to collect payments. Anil and I both loathe entering credit cards into web pages. Our target customers already have Amazon accounts. We felt that the user flow for backing Kickstarter projects, which ThinkUp would emulate, was so smooth and easy it would enable even impulse backers to pledge a subscription on their tiny mobile device screen.
Because it was a crowdfunding campaign modeled closely after Kickstarter's flow, there was one particular requirement that had serious repercussions for us down the road. During the campaign we'd collect credit card authorizations—agreements from our backers to let us charge them when the product was ready. We promised we wouldn't charge anyone until January, when ThinkUp was available for them to use.
This had two big implications on the backend: first, we'd have to use Amazon Flexible Payments Service, Amazon's more advanced, customizable payments API which allowed apps to collect authorizations first and not charge till some much later date. It also meant we could put off writing any software that performed actual charges until later.
So while over 1,000 backers gave us permission to charge their Amazon account a lot of money in aggregate, our system wasn't ready to do that—until a special day in January, the 17th, when it was time to run the charges. That day we collected a lot of money from our backers—and a hell of a lot of payment failures.
Remember the Target hack? Forty million credit cards were compromised, and a great deal of them were owned by people who backed ThinkUp's crowdfunding campaign. In the time between ThinkUp collecting the authorization to charge their card, and the charge itself, almost a third of our backers had changed their credit card thanks to Target. And thanks to things like Gmail's Priority Inbox (a majority of our subscribers use Gmail), spam filters, and just busy people who don't get through all their email every day (like me), a majority of those failed payments went unfixed because backers simply never saw the multiple emails from us and Amazon alerting them to the failed payment.
While I am eternally grateful to every single human who backed our campaign, failed payment or not, it was a bummer.
Project 2, March 2014: Annual subscriptions
ThinkUp launched on time to its crowdfunding backers in January, but it was available to only them. We weren't yet open to the public. Mostly this was because ThinkUp the product had a lot of bugs to work out, but we also didn't have the billing system in place to collect an authorization and charge it immediately. Each day, by hand, I'd run a script that collected stray charges left over from the crowdfunding campaign, and we scrambled to put out instructions on how to update your payment method and fix failures.
In March we finally opened up to the public, and began accepting annual subscriptions on the spot. We were still using Amazon's Flexible Payments Service, with the key difference that the charge happened immediately after the authorization. The immediacy of the charge cut down on payment failures a whole lot.
Project 3, July 2014: Free trial
Once ThinkUp was open to the public, the software was a reality, and we'd exhausted the goodwill of crowdfunders who were inspired by an idea presented in a video, it was time to get real. ThinkUp's annual subscription price was pretty high ($60/year for members, $120/year for Pro plans). Without a way to try the app out first, our subscriptions slowed to a trickle, and cancellations after a week or two of using the service spiked. We had to offer a free trial.
Our one big requirement for the free trial was that we could say: "Credit card not required." We hate free trials that collect your payment information upfront, and then when you forget to cancel, charge you automatically. So, on the backend, this project had less to do with billing, and more to do with building in a trial state where the user hadn't paid yet but was still getting access to the full app. We also needed reminder emails letting trialers know they had X number of days left to pay in order to keep their account active.
Once we launched free trials, it was a thrill to see so many people try out the app. This is when, as a business, we started concentrating on converting users—not just from landing page to signup, but from trial to paying subscriber.
Project 4, August 2014: Monthly subscriptions
With free 14-day trials in full swing, we poured a great deal of effort into making the first 14 days of app usage the best they could possibly be, in order to convert more subscribers. But the annual subscription fee was still pretty high, and we fiercely debated internally if we could market a $60/year product as $5/month. Not until our customers could actually PAY monthly, I argued.
It wasn't until we had to offer monthly subscriptions that all the highly-customizable-but you-gotta-do-it-yourself of Flexible Payments Service (FPS) became a liability. I didn't want to create cron jobs that ran daily charging people on a monthly basis. That figured out if someone paid on January 30th that it should recharge them on February 28th the next month. That had to deal with timezone stupidity. That meant we lost revenue if our servers had a problem. I wanted someone else to handle all that for us.
We were still convinced that Amazon Payments was the best user interface. So, since we wanted to stick with Amazon Payments, we switched to Amazon Simple Pay, a wrapper for FPS that handles recurring charges for you. Subscribing to a service via Simple Pay was still a one-click affair, and Amazon did all the recurring charges for you. Great!
Around this time, our Amazon Payments account manager got in touch, pitching Amazon's new payments product, Login and Pay with Amazon (LPA). He wanted to set up a call about ThinkUp migrating to LPA. I looked at LPA's documentation, and it appeared to be built for web sites selling physical products, geared towards businesses who needed a full shopping cart experience and had to collect shipping addresses. It didn't support recurring subscriptions. That wasn't for us.
In a decision I regret to this day, we decided to go with the older, established Amazon Simple Pay instead of the new Login and Pay. Even though LPA didn't offer features we needed, I ignored very obvious signs that Simple Pay was no longer on Amazon's roadmap. The code libraries hadn't been updated in years. For a business as small as ours, our Amazon account manager pursued us with a lot of persistence to consider switching over.
We didn't.
Project 5, November 2014: Coupon codes
It's not easy getting consumers to pay for recurring subscriptions on the web. In an effort to boost our sales during the holiday season and give users the opportunity to give ThinkUp as a gift, we launched The Good Web Bundle. A partnership with four other subscription sites that we love, a user could purchase the "bundle" for a discounted price. When they did, they received a coupon code they could redeem at ThinkUp and at the four other sites for one year of use.
The big difference between this project and the earlier work we'd done was this was the first one-time purchase a user could make. We used Amazon FPS to give users a link to make that one-time purchase, then emailed them a unique coupon code. Just like the other four sites, we built in the ability to redeem that code for a year of ThinkUp in our membership system. Similar to free trials, this was a matter of creating a non-recurring subscription state in our system that ended on a date exactly a year away from redemption.
It was around the bundle's launch that we heard a troubling rumor from a reliable source. Amazon was going to discontinue Flexible Payment Service (including Simple Pay), and go exclusively with Login and Pay. Kickstarter was switching to Stripe.
THAT put a damper on the holidays.
Project 6, January 2015: First annual renewals
In January, our first annual renewals were up from the crowdfunding campaign. Since those came in via FPS and not Simple Pay, we'd have to recharge them manually. We were hyper-aware that most crowdfunding campaigns do NOT charge you again a year later, so we spent a good amount of time writing and designing email notifications for crowdfunders informing them that their annual renewal was coming up. We sent one 2 weeks before the member's renewal was due, and one week before. I wrote code that gave users the ability to close their ThinkUp accounts and get a pro-rated refund via FPS right inside ThinkUp. (Prior to that, they had to email us, which sucked.)
Then, each day we ran the annual renewal charge job by hand as members came up on their renewal date. There were a ton of payment failures again, due to expired or changed credit cards, and a good number of users closed their accounts because they hadn't used ThinkUp as much as they thought they would. That is understandable, if hard to watch. I was glad to finally give our members a guilt-free escape hatch if they wanted out.
Project 7, March 2015: End-of-life
In January, Amazon made the announcement official: Amazon Flexible Payments Service (FPS) would be discontinued effective June 1, 2015. Worse! Existing subscriptions would NOT get automatically migrated over to Login and Pay. Our customers would have to come in and pay again.
In short, the payments API our entire business was based on, and the sole source of our revenue, was going away. I'll be honest: I spent a couple of weeks feeling crushed. We'd worked hard to acquire every single paying ThinkUp subscriber, and we know that in the transition, because of lost emails or busy lives or second thoughts, we will lose customers. Not to mention rewriting our billing interactions and backend again to work with Login and Pay.
We thought long and hard about moving to Stripe. To Amazon's credit, our account manager and a migration engineer spent a great deal of time with us, offering help, making suggestions, accepting bug reports. Login and Pay does not support recurring subscriptions, and that was not software I wanted to write in-house. Among a handful of other products, Amazon suggested we check out Recurly, which offers recurring subscriptions via Login and Pay. Beyond offering way better customer management features than Amazon Payments itself does, Recurly offers integration with Stripe and PayPal, generates customer invoices, and made offering both a monthly and an annual subscription plan very easy.
So, this month, we removed the Amazon Simple Pay code from ThinkUp, and we're now accepting payments via Login and Pay with Amazon (by way of Recurly). The customer experience is just as simple as it always has been, with one additional choice: between a monthly or a discounted annual plan. Recurly, of course, takes a cut, but given the dev time they saved us and the features we'd never build by hand, it's worth it.
In conclusion
Having been through these past 19 months of billing system development, I truly appreciate the value of app stores, and how they let software developers worry about their software instead of accepting payments.
It might seem like the moral of the story here is "Don't depend on third-party billing services—especially Amazon Payments!" But I don't believe that. As a small startup you don't have a choice about depending on third-party services that could get pulled out from under you on any given day. Even all this was more efficient than building our own in-house credit card transaction service. And there's no telling how things would have played out if we had, say, gone with Stripe from the beginning. Maybe we would have skipped a lot of steps in this journey so far and had a ton more time to focus on ThinkUp the product versus handling subscriptions. Maybe we would have had a lot fewer customers who didn't want to enter their credit card into a new app they didn't trust yet. Maybe in the end the dev time we saved would equal the revenue we'd lose. (Though I'm not sure Stripe would have supported delayed charges the way Amazon FPS did at the end of 2013.)
When I started building subscription payments into ThinkUp, I had zero experience and only vaguely understood the difference between a credit card authorization and a charge. I was dumb. Today, so far, I'm really happy to pay someone (sometwo, actually, between Recurly and Amazon) to do the work of dealing with payments, invoices, recurring charges, and expired credit cards for us.
Amazon FPS and Simple Pay will stop charging our customers as of June 1. Between now and then, our EIGHTH billing project will be asking our current customers if they will re-pay for their subscription. Wish us luck.
