schaunwheeler

Why should we assume that the way SMS, phones, mail, notifications and other channels have been handled in the past is the way they must always be handled? I work with a lot of those marketers. It's not like they're sitting in front of Braze in a black top-hat, twirling a curly mustache with their fingers, and saying "heh heh heh, how I can annoy all of my users today?" They hate that there isn't a better way to reach people. There are better ways - I know because I'm building one of them and can see how it reaches people when they want, about what they want, and as frequently as they want, and how the engagement and purchase rates are way higher for those individualized messages than they are for dumb blast messages.

It's not inevitable that a tool with a glaring technical flaw must always have that technical flaw. Technical flaws can be fixed.

It feels like you're assuming a traditional marketing approach to "blasting" messages and hoping they stick. That's how most marketing tools work, but it's not how all marketing tools work, and I think it's a mistake to treat an implementation flaw as an indicator that a technology isn't actually desirable. It's not desirable in its current form. That doesn't mean it has to stay that way.

It's in people's nature to take sides, and, as you pointed out, technology serves whomever happens to control it. So people who control technology should use it to try to help other people. I realize it doesn't often work out that way, but I see no reason to give up on the ideal. In the end, it's in the interest of those who control the technology to make the end-users happy. If everyone actually turned off all push notifications, companies that send push notifications would have a useless channel. It's not in their interest to spam people, and from personal experiences I can say that I think most of them know that. The tool set for sending smart notifications has just been incredibly limiting until recently.

Lot of strong feelings here about push notifications :) I think it's worth pointing out that (1) there are many people out there who find push notifications useful or even desirable, and (2) push notifications don't need to suck. Most push notification are annoying nudges because tools that allow companies to send notifications only allow mindless mass blasts with maybe a bit of only-slightly-less-mindless segmentation scattered in. There are better ways to do it. I'm helping build one of those ways (aampe.com), but my point is that we should distinguish between the current state of the technology and the potential of the technology to meet a valid need.

Let's take the bike company example. There are three main ways you could vary our outreach to potential customers: time, topic, and text.

Just think about timing: when is the best time for someone to get a message from you? There are aggregate stats about certain days or time being better for open rates, but customers aren't a monolithic entity. Some times work for some customers, and other times work for others. We've found that timing decisions have huge impact on ROI in industries ranging from gaming to retail to food delivery.

Now look at topic: what kind of bike do you try to interest them in? Do you try to interest them in a bike at all, or do you pitch a helmet, or shorts, or repair services. Personalizing topic is the essence of a recommender system, which has been discussed elsewhere in this thread, and it's possible to get something like that, even for a bike shop.

Then you have text: let's just look at value proposition. Do you appeal to their love of the open road? Their desire to exercise and get more fit? Spend time with their families? Replace an old bike that's causing them maintenance headaches? By learning what aspect of biking individual people care about, you can tailor subsequent communication to emphasize those things.

A bike company has virtually endless ways to tailor their message.

This article is a combination of a straw-man argument and a bad analogy. The authors say [personalization] = [3rd-party data categories] * [appeals to non-universal emotional associations]. They show that 3rd-party data categories are crap. Anyone who has worked with those sources knows about the bad quality, so the criticism is an easy sell. Then they use an analogy of Disney/Pixar movies to argue that messages should have universal appeal. Most everyone feels all the feels when they watch a Disney/Pixar movie, so this is also an easy sell.

Pull the straw-man apart a little bit: 3rd-party data isn't the only data out there. There's at least one solutions (full-disclosure: I'm building it) that uses high-frequency communication channels like push notifications as a factory to originate 1st-party data that's tailored to your business needs and exists at the individual level. In other words, saying personalization based on 3rd-party data doesn't work is like saying a car that with water in the gas tank doesn't work. Of course it doesn't. Stop putting water in the gas tank.

Now look closer at the analogy: like a good movie, a good marketing strategy will expose customers to a wide variety of reasons to engage, so they can take what is personally meaningful to them and leave the rest. You can't fit the whole strategy into a single message. Of course you can't, just as Disney/Pixar can't fit every emotional association into a single scene scene. The authors point out the obvious fact that personalization can't fully happen at any single point in time, and miss the point that personalization necessarily happens progressively over multiple points in time.

I don't mean to come down hard on the authors of this post. They're reacting to what most marketing platforms call personalization. The problem isn't that personalization is impossible and doesn't work. The problem is that so many platforms have implemented something that doesn't work and have called it personalization.

For anyone interested, my co-founders and I have written several blog posts covering both what real personalization should look like, and many of the technical aspects of how it can be both possible and effective: www.aampe.com/blog

I wrote this specifically for data science jobs but I think it translates reasonably well into any technical role:

https://towardsdatascience.com/data-science-career-advice-to...

The short answer is that it all depends on what you are looking for in a position.

The longer answer is ask them what they do (as a company, team, etc.), then ask them what infrastructure (technical and organizational) they have in place to do that. Then ask them about non-managerial growth paths (unless you're a manager).

Finally, ask them to give you a question - some business problem they're trying to solve - that they themselves don't know the answer to. Ask to sit in a room with the people who would be involved in planning a solution to that problem, and actually plan out the initial steps of solving it. That will tell you more about the team dynamics and the workplace environment than any explicit questions you might ask.

Here are some ideas:

https://hackernoon.com/can-we-be-honest-about-ethics-ecf5840...

https://towardsdatascience.com/an-ethical-code-cant-be-about...

https://hackernoon.com/on-the-difficulty-of-creating-a-data-...

I've tried to flesh out some of the discussion of systemic risk here:

https://hackernoon.com/can-we-be-honest-about-ethics-ecf5840...

I'm not questioning the documents' merits, or the intentions of those who wrote them. I'm concerned about the downside potential they introduce through systemic risk.

Thanks! I filled out the survey.

A few things:

1. I never claimed the MVP was just whipped together. I claimed it was an MVP. I'm aware that this has been worked on for months - I joined the Slack channel and tried to participate. You made a straw-man argument.

2. The piece of my mine you linked to was never posted in the D4D slack. Or in any other community discussion. At least not by me. You resorted to an ad hominem attack on me personally instead of a principled attack on my position.

3. You stress the fact of this being a living document as if that had something to do with my concerns. Living or not, it went into production without fully considering the downstream harm the product could cause. You avoided my actual argument with a red herring instead of engaging it.

Given all of the above, why should I accept that your invitation to participate in the data.world slack was extended in good faith?

If anything in my original post seemed to warrant the hostility of your response, then I beg your pardon for poor wording. But my argument still stands.

Exactly. The cost of fixing a bug after the product is out the door is much higher when the bug is ethical rather than technical. Therefore, don't move the product out the door so quickly. Ethical QA takes time.

I don't think training and sharing of knowledge is the problem. The problem is creating an appropriate incentive structure for maintaining trust in individual practitioners' competency. That doesn't happen in a top-down way. It has to be negotiated as locally as possible.

I agree with this. There comes a point (much sooner than most people like to recognize) when quality and safety get sacrificed to just getting things done. However, I think that's a manageable risk. Most focus - and tooling - centered on analytic/technical design rather than implementation has the potential to catch problematic implementations before they're shipped.

https://towardsdatascience.com/data-is-a-stakeholder-31bfdb6...

It's not fool-proof, of course, and I think a change in perspective away from just moving fast and breaking things would be quite healthy for the industry as a whole.

A think a governing body solves the wrong problem. Most of the ethical issues that have arisen around data science in particular are actually competency issues. It's not that someone deliberately set out to target already-vulnerable populations. It's that they designed systems without building in checks for unintended consequences. A governing body accomplishes what any legal framework accomplishes: it provides instruction and incentives to limit liability. A legal framework is different than an ethical framework. What we need is an ethical framework.

The original Hippocratic Oath did a fairly good job of this by stipulating ways that a doctor could prove his competence. Doctors who adhered to the oath weren't better doctors because they had some kind of internal moral compass or external adjudicating body. They were better doctors because only the doctors who had competency to spare were willing to make the sacrifices that adherence to the oath required.

https://hackernoon.com/on-the-difficulty-of-creating-a-data-...

Ethical problems get solved (as much as that type of problem can ever really be "solved") by individual practitioners refusing to work with other individual practitioners who refuse to adhere to some basic best practices. That creates a network of competent and trustworthy individuals, who are still totally fallible, but who put their own practice up toe constant public scrutiny.

Ethical problems are problems of systemic risk. Systemic risk doesn't get solved through organizations.

I find that people in tech, especially in my own field of data science, treat ethics as a relatively simple problem. If they were building a technical product, they would at least make an appearance of checking assumptions, and worrying about breadth and depth of stakeholder buy-in, and building tests for unintended consequences. But when it comes to building an ethical "product" to guide their work, it's like all of the best-practices go by the wayside. For example:

https://www.wired.com/story/should-data-scientists-adhere-to...

Data for Democracy came up with an ethical code for data scientists and is now talking it up asking people to sign on to it. The thing is basically the product a few months of working groups plus a day-long hackathon, and it's already been put out on the market, so to speak. So it's not surprising that they produced something that could, in many ways, actually run counter to their goals. I firmly believe the ethical code as written is itself unethical:

https://towardsdatascience.com/an-ethical-code-cant-be-about...

What I've found amazing is that the community that built the D4D ethical code has been entirely unwilling to invite criticism of the code, or even engage with those who question it. The fact that willingness to entertain criticism and consider unintended consequences is actually one of the pillars of their ethical code makes it doubly troubling.

A lot of people in this thread are focusing on technical tools, which is normal for a discussion of this type, but I think that focus is misplaced. Most technical tools are easily learnable and are not the limiting factor is creating good data science products.

https://towardsdatascience.com/data-is-a-stakeholder-31bfdb6...

(Disclaimer: I wrote the post at the above link).

If you have a sound design you can still create a huge amount of value even with a very simple technical toolset. By the same token, you can have the biggest, baddest toolset in the world and still end up with a failed implementation if you have bad design.

There are resources out there for learning good design. This is a great introduction and points to many other good materials:

https://www.amazon.com/Design-Essays-Computer-Scientist/dp/0...