GoDaddy Conversations
TIMELINE
Summer 2026 Internship
GoDaddy — Conversations Team
Weeks 2 – 5
TOOLS
Swift · UserNotifications
APNs via Braze
iOS Notification Categories & Actions
Quicksight (usage analytics)
MY ROLE
Team of 2: Arisha Gupta, Ayaan Kumar
Mentors: Ash Zhong, Dani, Javier, Kim (Mobile UI/UX)
Led cohort research and shipped the iOS quick-action implementation
PROJECT CONTEXT
Product: GoDaddy App — Conversations
Platform: iOS (UserNotifications / APNs via Braze)
Business owners ("C1s") using GoDaddy Conversations rely on mobile push notifications to know when a customer ("C2") has reached out through a website contact form, chat widget, or SMS. Customer complaints and NPS feedback repeatedly cited missed notifications, delayed responses, and lost leads. This project investigated why that friction existed, identified the highest-value user segment to target, and shipped a working set of iOS Notification Quick Actions (Reply, Resolve, Snooze, Remind Later) plus notification stacking — all integrated into the live GoDaddy app and backend.
THE PROBLEM
For C1s, the current notification experience didn't consistently drive fast, confident responses. Some customers reported not receiving notifications at all; others had to fully open the app and navigate before they could act. This created friction that led to missed or delayed responses to real customer inquiries.
How might we help C1s reliably notice and act on important inbound website messages from push notifications, especially when speed matters?
Beyond delivery, early research surfaced three more friction points: duplicate notifications for customers still running both the legacy Conversations app and the GoDaddy app; all-or-nothing notification control, with no way to pause for a window of time without disabling entirely; and insufficient context in contact-form notifications — a name and a message snippet isn't enough to triage priority among many inbound leads at scale.
EARLY RESEARCH: DELIVERY OR UX?
Delivery Chain
— 100% of notification requests were confirmed received and sent by our platform
— The gap showed up between the platform and the iOS/Android client, not at ingestion
APNs Funnel
— Apple's own delivery console showed ~1M pushes sent to APNs
— Only ~324K were actually delivered to a device — most blocked by offline status or Focus mode
Open Question
— Hard to fully separate genuine delivery failures from users who had notifications disabled
— Flagged: instrument offline vs. Focus-mode blocks specifically, to isolate the true "not receiving" population
SUCCESS METRICS FRAMEWORK
To evaluate whether notification improvements actually work, we proposed:
Notification-to-response rate — % of delivered notifications resulting in a reply within 1/4/24 hours. The core health signal for the whole system.
Notification opt-in retention (30/60/90-day) — whether users who enable push notifications keep them enabled over time.
Response time P50/P90 — median and worst-case time between a customer message and the owner's first reply.
Conversation resolution rate — % of conversations reaching resolved/closed status within a time window, the downstream outcome every other metric feeds into.
Engineering confirmed the team already collects received-to-tapped rate and tapped-to-launch attribution rate, which help quantify how many users engage with a notification once it arrives and how many go on to act in-app.
GROUNDING THE PROBLEM IN DATA
Pulling from internal 30-day Quicksight snapshots, the data reinforced a genuine engagement gap:
Conversations receives 2.4M–3.4M threads and 5M–6M messages per month, but the average conversation length is only ~1.7–2.0 messages — most threads end without real back-and-forth.
At the website-messaging level specifically, businesses averaged only 30–40 threads and 60–70 messages per month.
A large share of threads showed a "passive C1 / no C2 response" pattern — plausibly tied to notification breakdowns rather than pure disinterest.
A drop in thread/message volume in July 2026 was attributed to a platform-side anti-scam rollout, not a notification issue — an important caveat when reading the trend.
Two cohorts emerged with distinct needs: website/contact-form users (~30–40K, the largest cohort, actively migrating to the app) whose core pain is prioritization when volume is high; and telephony users (the next cohort in the migration queue) whose core pain is reliability, since missing one call can mean losing the business entirely.
TARGET COHORT & USE CASE
Recommended cohort: C1s with a GoDaddy website with website messaging enabled, receiving inbound messages via contact forms, chat widgets, or similar inputs — operationally defined as:
— Has an active contact surface on a GoDaddy website
— C2 initiates contact via chat widget, contact form, email, etc.
— Has the GoDaddy mobile app on iOS
— Has Conversations notifications enabled
We drafted realistic business-owner scenarios to stress-test which features would matter most: a hands-on owner who sees a notification but may forget it later; a larger business triaging a batch of messages during a busy period; an owner mid-task deciding whether a new message is worth interrupting for; a multi-location owner needing to know which business a message pertains to; a multi-staff team wanting visibility into whether a message was already handled (maps to GoDaddy's existing web-only "Assignment" feature, mobile planned for Q3); and an owner who should immediately recognize a high-intent message — a booking, purchase, or quote request — using AI categorization the backend already runs but had never surfaced client-side.
Two scenarios were prioritized above the rest: (1) does the notification give an owner enough context to decide whether to interrupt their current task, and (2) can the notification signal high-value inquiry types using the AI categorization that already exists on the backend. Both directly shaped what we built in Weeks 3–5.
WHAT WE BUILT (WEEKS 3–5)
Reply
A quick-reply text field embedded directly in the notification's long-press menu — an owner can answer a customer without ever opening the app.
Resolve
Marks the conversation resolved straight from the notification, for the common case where no reply is actually needed.
Snooze
A one-tap "Snooze for 10 min" action for the hands-on owner who saw the notification but genuinely can't act on it yet.
Remind Later
Opens a native date/time picker so an owner can set a custom reminder — for messages that need real attention later, not just a 10-minute buffer.
Notification Stacking
Groups multiple notifications from the same conversation instead of piling up as separate alerts — directly targets the "batch of messages during a busy period" scenario.
Reply
Resolve
Snooze
Remind Later
Notification Stacking
CHALLENGES
iOS Notification Categories & Actions
Each quick action required registering UNNotificationCategory actions client-side and coordinating matching action identifiers with the backend payload sent through Braze, so tapping an action in the notification tray triggers the right API call.
Quick-Reply Without Opening the App
The inline Reply field needed to hit the same conversation-send endpoint the in-app compose box uses, including error handling for a failed send when the user never sees app UI to retry from.
Separating Delivery Reliability from UX
Much of Week 2 went into confirming we were solving the right problem — distinguishing genuine APNs delivery loss (offline devices, Focus mode) from a UX problem within our control, since the two needed completely different fixes.
IMPACT & NEXT STEPS
Reply, Resolve, Snooze, Remind Later, and notification stacking are live in the GoDaddy app for iOS. Because these features ship directly into a production app already used by tens of thousands of business owners, impact is being tracked against the Success Metrics Framework from Week 2 — notification-to-response rate, opt-in retention, response time, and conversation resolution rate — rather than a one-off demo metric.
Next steps:
— Instrument offline vs. Focus-mode block reasons specifically, to separate real delivery failures from disabled notifications
— Extend message-type prioritization using the backend's existing AI categorization (booking, purchase, quote) directly in the notification itself
— Bring the reliability-first fixes identified for the telephony cohort into their own follow-up scope
REFLECTION
This project underscored how much research has to happen before a single line of notification code gets written — figuring out whether we were even looking at a delivery problem or a UX problem shaped everything that came after. Working alongside engineering, design, and product stakeholders meant constantly translating between what the data showed, what users described, and what was actually feasible to ship inside four weeks.
Getting Reply, Resolve, Snooze, and Remind Later into a production app used by real business owners — not just a prototype — was the most rewarding part of the internship, and a reminder that the choice of which two scenarios to prioritize mattered as much as any single line of Swift.
ARISHA GUPTA © 2026 — SEATTLE, WA