Re:BUiLD Cash-Plus Targeting

Shiny recommender for IRC field teams — application layer from causal targeting models

Application development · Georgetown gui2de · IRC Re:BUiLD

From targeting models to a field recommender.

I built the Shiny application that turns gui2de cash-plus targeting analysis into a decision-support tool for IRC caseworkers: score one applicant or a batch, compare Cash only versus Cash + Network, and see a plain-language rationale with cost-aware economics.

Open live app → gui2de profile → gui2de Re:BUiLD page →
6,260Programme participants in the training sample
2Cities — Kampala and Nairobi
16Applicant features in the parsimonious model
AppNamed Application role on the product

My role (accurate credit)

On the product’s Targeting Development Team I am listed as Application (gui2de East Africa): I developed the Shiny recommender from the targeting models so field teams could use the analysis operationally.

Role Person Unit
Academic lead: targeting Andrew Zeitlin gui2de
Analyst Ethan Sager gui2de
Application Nichodemus Amollo gui2de East Africa
Project management Alex Wendo gui2de East Africa

I do not claim sole ownership of the causal forest or the working-paper analysis. I claim the application layer: assessment UX, economics inputs, recommendation presentation, batch workflow, and deployment of a tool caseworkers can run.

Targeting Development Team credits showing Application: Nichodemus Amollo
On-product team credit — Application: Nichodemus Amollo, gui2de East Africa.

Programme context

Re:BUiLD (Refugees in East Africa: Boosting Urban Innovations for Livelihoods Development) is a multi-year initiative led by the International Rescue Committee with support from the IKEA Foundation, pairing livelihoods services for refugee and host-community residents of Kampala and Nairobi with rigorous evidence generation. Georgetown gui2de supports the research and evidence layer.

Live tool: rebuild.shinyapps.io/rebuild-targeting

Problem the app solves

Average treatment effects hide real heterogeneity: networking helps some participants much more than others, and networking is more expensive to deliver than cash. Field teams need a participant-specific, cost-aware recommendation that still leaves the final call with the caseworker.

What the recommender does

  1. Enter a profile — screening characteristics (e.g. age, baseline monthly revenue, refugee status, language fluency, and related fields).
  2. See the prediction — estimated change in monthly income if networking is added to cash, weighed against delivery cost.
  3. Review with judgement — clear Cash only or Cash + Network recommendation with rationale and cost-benefit comparison.

Also supports batch upload so programmes can score a list of applicants, not only one-by-one.

Re:BUiLD targeting app home page introducing cash-plus targeting for IRC field teams
Product home: decision support for IRC field teams, grounded in a causal forest trained on 6,260 real programme participants.

Methods spine (for technical readers)

  • Model family: causal forest (Wager & Athey; grf in R)
  • Estimand: conditional average treatment effect (CATE) of Cash + Network versus Cash only
  • Training sample: 6,260 Wave 2 programme participants across Uganda and Kenya (Kampala and Nairobi)
  • Decision rule (app logic): compare CATE to an opportunity-cost expression built from programme economics (cost of cash, cost of networking, benefit of cash)
  • UX requirement: every recommendation needs a rationale and a cost-benefit comparison, not only a score
Participant assessment screen recommending Cash + Network with expected net gain
Assessment UI: programme economics and applicant profile on the left; recommended placement, expected extra income, and net gain on the right.

Caveats the product is honest about

  • Recommendations are advisory; caseworkers keep final judgement
  • Model fit is specific to the training contexts and waves; do not casually extrapolate to new countries without re-training
  • Cross-site transport of targeting rules is a research concern, not something the app pretends is solved
  • Use non-identifying participant IDs unless the deployment environment is approved for identifiable data

What this demonstrates

  1. Turning research models into field software under partner branding and real users
  2. Clear role boundaries (application vs academic lead vs analyst)
  3. Cost-aware causal targeting presented in language caseworkers can use
  4. Deployment discipline (Shiny, methodology tab, batch + single assessment paths)