Segment explorer and broadcast send desk for Customer.io

Build me an app for reviewing Customer.io audiences before I send to them. Today it is hard to see who is actually inside a segment until after a broadcast has gone out, so this app is a segment explorer joined to a send desk. It has two main tabs: Audiences, where I browse and compare segments and start a send, and History, where I see what has already gone out for a given broadcast.

The Audiences tab opens on a list of every segment in the workspace, loaded with Customer.io List Segments. Show name, segment id, type, and size in a table I can search by name and sort by any column. If the segment listing does not return a member count for a segment, leave the size cell blank with a small control to calculate it on demand. Do not page through the membership of every segment just to populate that column on first load, because that would be thousands of requests before I see anything.

Clicking a segment opens the member browser, backed by Customer.io Get Segment Membership. That operation is cursor paginated: each response carries a next token that must be passed back as the start parameter on the following call, and you keep going until the token is empty. The default page size is 1000 and the maximum is 30000, so request a moderate page (around 500 to 1000) and give me a Load more control plus a visible count of how many people are loaded so far out of the segment total. Show the person identifier (id, email, and cio_id) alongside their traits as columns, let me search across everything already loaded, and let me sort on any trait column. Every row has a checkbox, with select all on the current page and a persistent running count of how many people I have selected.

The compare view lets me choose two segments and see how much they overlap. Load the membership of both with the same paged reader, then intersect them on the workspace primary identifier. Report three numbers clearly: only in the first segment, only in the second, and in both, plus the overlap as a percentage of each segment. List the overlapping people in the same table component used by the member browser. Because both sides have to be fully paged before the numbers are exact, show progress while loading and make it obvious when a total is still partial rather than quietly showing a wrong number.

From a segment view or an overlap list I select recipients and open the send desk. There is no operation that lists broadcasts, so do not build a broadcast picker that fetches them. Instead let me maintain my own small roster of broadcasts inside the app: I add an entry with the broadcast id and a friendly label, the app saves it, and the send desk and History tab both choose from that saved roster. Let me edit and remove entries.

Sending uses Customer.io Trigger Broadcast, and the most important rule to get right is that the audience is exclusive: the request accepts exactly ONE of recipients, ids, emails, per_user_data, or data_file_url, and sending more than one is invalid. Model this as a single audience mode selector rather than a set of independent fields. When one mode is active, the inputs belonging to the other modes are disabled and cleared so I cannot half fill two of them. Expose these modes: explicit person ids, explicit email addresses, per person data where I supply recipients together with their personalization values, and a filter that describes the audience instead of naming people. Validate before sending and block with a plain explanation if the payload would carry two audience types.

For personalization, give me a shared data section that applies to the whole send, and, when I am in the per person mode, an editable grid where each selected recipient gets their own values. Prefill that grid from the traits already loaded for those people so I am not retyping names. Before I confirm, show a review panel with the broadcast label, the audience mode, the exact recipient count, and a sample of the merged data for the first few people.

Two guardrails matter. First, I set an audience size threshold that the app remembers, and any send that would reach more people than that has to pass a confirmation dialog naming the real count before it goes. Second, API triggered broadcasts are rate limited to one request per ten seconds per broadcast, so enforce that in the interface: after a successful trigger, disable sending for that specific broadcast id with a visible countdown, key the cooldown per broadcast rather than globally, and serialize sends instead of firing several at once. Also pace the membership paging, since the Customer.io app API allows about ten requests per second for the workspace overall, and if a request comes back rate limited, back off and retry rather than looping.

The History tab shows what already went out. I pick a broadcast from my saved roster and the app calls Customer.io List Broadcast Triggers to show every trigger for it, newest first, with the trigger id, when it ran, its status, and how many people it reached. Clicking a row calls Customer.io Get Broadcast Trigger and opens the full detail, including the data that was sent and the recipient filter that was used, so I can see exactly what a past send targeted.

Anywhere I am looking at a list of people, a segment view, my current selection, or an overlap result, I can export it to Google Sheets with Append Values. Let me choose the spreadsheet and tab, write a header row when the tab is empty, and include the segment or comparison name, the identifier columns, the trait columns currently shown, and the time of the export. Remember the last spreadsheet and tab I used so the next export is one click.

Persist per user of the app: the saved broadcast roster, the audience size threshold, the export destination, and my column and sort preferences in the member browser. The app is read only against Customer.io apart from sending: it never creates, edits, or deletes segments or customer records, and the only writes are triggering a broadcast and appending rows to my spreadsheet.