Areas / constituencies about proca HOT 15 CLOSED

Overall, I agree with @tttp's approach here

First step would be just that Proca attaches "external ids" of constituents and records it.

How the lookup based on different parameters could work and map to these external ids:
Yeah, that's tricky. The minimal is saving these tables in Proca and having ppl upload csv's or something to update them, and even that will be a pain.

So yes, I would say the Proca user needs to provide a lookup api.

There's no standard for how a clientside "lookup" api could work, but maybe look at 38's MEP tool + EU + I can send the USA mapping if you like.
And just come up with something simple like "we will send you whatever geo data we have and you will respond with an external id that we will save"
i.e. client asks something like this:
{"address": "", "city":"Tel Aviv", "postal":12345}
and the server just responds with:
{"constituent_external_id": 1234, "title":"Prime Minister", "name":"Angela Merkel"}

With regards to what Proca could offer on the front end: I wonder if 1-3 simple parameters during setup are enough to display a nice OpenStreetMap autofill box. The parameters assigned during creation would just define what level of autofill you want, something like:

{"use_gps_sensor":false, "administrative_level_accuracy":"city"}

where "administrative_level_accuracy" could be country, county, city, zip, exact address, gps lat lng.

And Proca can just use OSM/Mapbox in the frontend to provide the best geographic autofill experience.

from proca.

@tttp @benjycook thanks for good input.
Indeed Proca could just get an external_id and store it, and treat it as opaque (so not understanding what it means, just pass this to the CRM).
The recipient is chosen before the journey starts, so this could be delegated to another tool.

One Speakout functionality where the recipient might be useful:

• Sending email to recipient that a signature threshold was met - needs recipient email.

from proca.

To talk about the area segmentation I know best (MEPs):

• the areas are mostly the country, but some countries have constituencies (area, like ireland, belgium and what UK had)
• ireland addresses don't always have a zip
• DE has some kind of "informal" area (legally, the MEP represent all the country, but some parties segment saying this one is covering bavaria). PL voted on lists per region, but that got somehow removed and now the PL MEPs cover the full country
• belgium has segmentation based on the language. It's kind of like a region, but in Brussels and a bunch of other cities, each citizen can choose if they vote for the dutch or french speaking list
• on some campaigns targetting committees (say 50 MEPs only), you end up with cases where you do not have an MEP from your country (eg if you are from Malta, chances are you won't have an MEP

and I personally prefer targetting based on the political party+language spoken by the MEP anyway ;)

All that to say:

1. what would really add value IMO is keep a list of targets (MEPs, PL ML...) and generate separate widgets that do the targetting+segmentation based on whatever the campaign need.

2. and do we really need something "generic" part of the CTA?

from proca.

Hi @marcinkoziej , so I'm revisiting this point with a hopefully fresher mind

What about we separate completely in 3 different tools:

1. get a list of target and their constituencies
2. map a supporter to their target (via constituencies, can include zip->constituency->target
3. record the action taken

rationale:

1. might be highly specific for the campaign and better handled by the campaign website, and
2. we might provide a generic zip->constituency, but not keen at all on the idea of having to maintain and update it for 200 countries (we been doing it for 28, it's hell)

so proca would only cover 3

as an example, let's take a target your MEP action tool: https://tool.mepwatch.eu that I wrote previously.
So far, it doesn't connect with proca, but potentially could (eg the first time I click on an action, I ask for the contact details (or after the first successful, or whatever)

for this campaign, this is dumb html (d3 in my case). I could make it smarter by using an api to help the targetting (in the EP case, it probably makes the most sense to use a geoip API so use theIP address to identify the country, but we could imagine an API (country, zip)=> constituency_code

So what about we/someone develop whatever funky targeting/UI on a per campaign basis, ask to share the code so it could be used later for another campaign... either simply copy paste or adjusted.

we could offer as a service 1. for some countries/target only (eg maintain a list of MPs in PL or MEPs in EU + constituencies details)
and 2. (eg given a PL zipcode, give me the constituency)

for 2. we can start with a simple generic tool (country + zip->constituency), but in my specific needs, IP->country is good enough and there a existing APIs for that

Anyway, all of that is outside of "core proca", that "only" does record actions.

some of them might be "Benji sent an email to Bibi", but how Benji found that his target is Bibi is handled by another component of the campaign

** thinking loud** I definitely like the idea of offering 1 + 2 for European Parliament, I am already doing it anyway ;)

dragging @benjycook in the bainstorm. What do you think?

from proca.

Another example from something I started for uplift (and France did an awesome work on building that map, it's really tricky do do a great map and highly specific for each country/campaign IMO)

FYI: the selection is done on a d3 map

https://action.uplift.ie/campaigns/public-homes-pledge-2020-elected the campaign is over so no CTA anymore.

from proca.

@tttp It would be worthwhile to evaluate 38d CRUMP except this is a non-libre dependency...

I am wondering about building some sort of google docs or Airtable API so orgs could easily create their own target/area/whatever databases and update their availability

from proca.

from proca.

Good idea - to separate this notifier as a separate service.

As for sending emails, I was thinking about supporting Mailjet/SES in the way speakout does and then it uses an already configured email sender.

from proca.

The most MVP/Core thing Proca could offer is email/webhook notifications that you setup when you set up the widget.
Give us an email/url, you'll get notified when you want (small ui for time based, threshold based)
Simple people give the target email, smart people can give their own and forward,
super users use a webhook.

Might be worth splitting this into 2 discussions...

from proca.

from proca.

How we implemented it so far, and I think it will serve us no matter the use case:

• host the list of recipients (eg list of members of the parliament) relevant to the campaign on a public url, including their area/constituencies
• have a micro-service doing the relevant geo-coding to retrieve the data needed to find the relevant recipient (eg the constituency based on the zip code)
• on the client side, filter the recipients that match the supporters' constituency

This seems to work fine, the downside it that every supporter needs to download ALL the recipients and then filter them in the browser, but I haven't seen any campaign that has more than a few k recipients at most, so it's not a lot to download

we send the recipient identifier to the server for processing/analytics and voila

from proca.

from proca.

from proca.

from proca.

This microservice could also be under the organization's control.

from proca.