Mailchimp’s Subscriber Hash

I learned something today. In sitting down to finish up my mailchimp functions, I wanted to create a mailchimp_remove_teacher_from_list(listname) function and a mailchimp_blanket_unsubscibe_teacher() function. I thought that, after my previous success, it would go quickly.

I was wrong.

Over here, in the docs, there’s reference to how to delete list members, which is what I basically want to do:

client.lists.members.delete(list_id=”, subscriber_hash=”)

I knew what a list_id was, but wasn’t sure what the subscriber_hash was. After a bit of Googleing (I thought I’d have to ask mailchimp for the hash) I found this page and was able to piece it together:

In previous versions of the API, we exposed internal database IDs eid and leid for emails and list/email combinations. In API 3.0, we no longer use or expose either of these IDs. Instead, we identify your subscribers by the MD5 hash of the lowercase version of their email address so you can easily predict the API URL of a subscriber’s data.

For example, to get the MD5 hash of the email address Urist.McVankab@freddiesjokes.com, first convert the address to its lowercase version: urist.mcvankab@freddiesjokes.com. The MD5 hash of urist.mcvankab@freddiesjokes.com is 62eeb292278cc15f5817cb78f7790b08.

In short, the subscriber_hash argument is something you produce at your end and use to look a subscriber up. There’s something elegant about it — you have no business accessing the subscriber if you don’t know the email address, already — but I needed some time to get it done.

Here’s how I did it:

import hashlib # A standard library that does hashes

# The following is in .lower() case because mailchimp forms
# hashes from lowercase strings.
# The .encode() method tagged on the end encodes it as a byte literal
email = request.user.email.lower().encode(encoding='utf-8)

# This uses the hashlib library to make the hash. The .hexdigest()
# seems to be about equivalent to str() [forgive me internet!]
hash = hashlib.md5(email).hexdigest()

client.lists.members.delete(list_id=list_id, subscriber_hash=hash)

This is not a complete solution. It basically tags onto my last post. At some point, I want to compend everything I do into something more universally applicable. When I do, I have no plans to keep it secret.

Advertisements

The Road Ahead

As I look at my coding journey, I realize I’ve stagnated a bit. I mean, I’m super proud of the Dynamic Worksheets program, but, to be honest, I’ve moved away from coding.

Lately, the coding work that I do is realizing that something is broken, and then spending an afternoon mostly realizing that my code really does make no sense. And then, eventually, finding the problem and fixing it. It is not as rewarding as actually building the thing was.

And, it’s not for lack of ideas. Or, really, for lack of time (though discipline is a thing that needs to be trained and maintained). I’ve kinda reached a place where I’ve lost track of my next steps.

So, it might help to write through this.

Logical next steps for the worksheet site

I had really hoped that I’d have users for the site before the end of 2017. And, though I shared it with a few people, only one of them actually went through the steps of making worksheets.

So, if I set “making dynamic-efl.com a community of teachers who actually use it (in Germany, at least) to make their classes better,” what are the logical next steps?

Here are the things it makes sense to work on in 2018:

  • Establish a list of exactly which “behind the scenes” tools I want before I advertise, and make them.
  • Draft the series of “welcome emails” as well as “explainer videos” that users will be sent/invited to view with time.
  • Write out a plan for how I’ll approach the market, planning on times to ‘force’ written reflection on lessons learned.
  • Implement the plan.

I’m not going to lie. Most of those things feel more like work to me, than like the play that creating the site was. I look forward to having people use something that I made, and think it’s fair to say that it’s not fully finished until people use it and value it.

So, what are the things I’m excited about doing?

Logical coding goals for the near future

I have ideas for other projects. They meet the standards of “things I would like to use” and “things I think would make the world better.” The thing is, starting a new project seems so daunting now that I see how hard it is to get a project truly finished.

Nonetheless, there are things that I think I can do to get ready for the next project. More than one Code Newbie podcast has included a guest saying something like “there is tons of Javascript in the world that wouldn’t need to exist if people would only learn CSS.” So, as an ongoing project, it seems to make sense that I find a good course and learn CSS before I get around to learning Javascript.

There’s something I’ve meant to get done that isn’t especially sexy. I’d like to create a bunch of reusable Django boilerplate that I could use for basic user management with projects in the future. This is based on the fact that I think I did users badly in the dynamic-efl project.

Django includes a basic User model, but I found myself wanting a lot of other things (some of which I haven’t implemented, yet) like email verification links, something to automatically delete accounts that haven’t been verified or logged into in the last year. There’s more, and I should write it down.

So, put all that together, and it seems that it seems as though it would make sense for me to set the following coding goals in the near future:

  • Pick a CSS course and learn it. (Possibly, also Javascript)
  • Practice writing a Django app that can be re-used
  • Write out what I want the Eternal Customer Model (working title) to be and do
  • Code the Eternal Customer Model and, finally, use it in a project such as
  • The Latin drill program.

That gives me stuff to work on. Look for updates.