Young adults will be recruited from the community through flyers, email listserves, and social media advertisements. A brief web-based screener will establish their initial eligibility. Eligible participants will provide contact information, and a research assistant (RA) will schedule the in-person baseline session.

A 90-minute in-person session will collect informed consent, demographic characteristics, and alcohol use data and identify possible peer participants. The RA will orient the participant to the project procedures, starting with installing the app on the participant’s phone and recording device characteristics (device manufacturer, model, and Android operating system version). The RA will assist participants in changing settings on their phones to ensure the app will work optimally, including setting Bluetooth, location, nearby devices, and notifications to on or allow, and checking that settings that pause activity (eg, pause app activity if unused) or remove permissions are off. The RA will demonstrate the app interface, including showing the participants how to initiate reports and respond to notifications. The participants will navigate through each report, view examples of response types (radio buttons and text fields), and practice making entries. They will be instructed to respond as soon as possible after a prompt. We will explain that they are expected to keep their phone on, charged, and nearby. We will verify that the participants are not planning on traveling.

The inclusion criteria for peers are as follows: (1) at least once a week in a typical week, having meaningful in-person social interaction with the participant. The alcohol-related inclusion criteria for peers are as follows: (2) between the ages of 18 and 29 years, and (3) drink with the participant at least twice a month in a typical month. While not all influential people with regard to alcohol use will be same-age peers, research indicates that same-age peers will most likely be present during drinking events (and in social interactions when drinking might occur) [32-34]. To identify possible peers, the RA will conduct a social network interview (SNI) that involves the participant nominating up to 10 people who they are close to, including friends, family members, or anyone they regularly spend time with in person who is close to their age [35,36]. The participants will report on the characteristics of these individuals, including their age, gender identity, whether they live together, relationship (friend, partner or significant other, casual acquaintance or coworker, sibling or cousin, other family member, and other), and frequency of meaningful social interaction (“How often in a typical month do you spend at least 15 consecutive minutes with this person?”). In line with the substantive study goals, we will also assess the frequency of the network member’s drinking (“How many times in the past month do you think this person drank alcohol?”) and the frequency of drinking with the person (“In the past month, how often did you drink with this person [while both of you were drinking]?”). For this protocol, we will ascertain the participant’s perception of the willingness of the peer to participate in this study.

Working with the RA, the participants will identify 3 peers to be invited to participate in the study based on eligibility. During the baseline session, the participant will attempt to contact each of the 3 selected peers to invite them to participate. If the participant contacts the peer with the RA present and the peer agrees to hear more about the study, the participant will, with the peer’s agreement, share the peer’s contact information with the RA, who will then provide the peer with a web link to the study description and informed consent procedures and will communicate with the peer about their participation from that point forward. If the peer does not respond to the participant in the presence of the RA, the participant will send the peer a brief study description with the web link. If any peer who has received the project description does not respond after 3 days, we will move to the next person on the SNI list and ask the participant to make initial contact with the (new) peer. The participants will be given 5 days to recruit up to 3 peer participants.

Once a peer participant has consented to participate, the RA will arrange a time to give them the beacon and answer any questions. The beacon is 4.4 cm square and 1 cm thick (Figure 1). We will provide a small adhesive patch to allow the peer to attach the beacon to their phone and a ring to facilitate attachment to their keys if they choose. Peers will carry their beacon for 3 weeks of the project. Each beacon is assigned a unique ID that associates the beacon with the participant and peer. The smartphone app reports will begin for the participants once the beacons are distributed to their peers. The peer participants will complete web-based surveys at the end of each of the 3 weeks of data collection, in which they will indicate the days and time of day in the prior week they did not have their Bluetooth beacon with them and times in the prior week they were with the participant. This information will be useful for determining why a beacon was not detected.

After the 3-week data collection period, the participants will complete a modified 15-item System Usability Scale (SUS [39]) with items adapted to our protocol that assess functionality (eg, “The app drained my battery” and “The app worked as expected”) with response options on a 5-point Likert scale from 1=strongly disagree to 5=strongly agree. We will also conduct a semistructured interview to clarify any reported functionality or validity issues. Before the interview, we will examine the participant’s beacon encounter data and reports of peer presence, and during the interview, we will clarify discrepant information, including reconciling signal-contingent reports (ie, indicating beacon detection) at times when the participant did not indicate that the peer was present. We will also probe the reasons for noncompliance and whether triggered report noncompletion appears to be systematically related to peer presence. In this final session, participants will be told how to delete the app from their phone.

The procedures were approved by the Brown University Institutional Review Board (protocol number 2022003448).

The participants and the peer participants will complete informed consent, which includes reviewing detailed consent forms, discussion with the researcher, and documentation of consent.

All information obtained during the assessments will be confidential and will be used solely for research purposes. To protect the data and prevent unauthorized access, all EMA data will be encrypted and will remain so until it is accessed by the project staff using a username and password specific to this project. All files with participant-identifying information will be password-protected and stored separately from the data on a server accessed only by the project staff. To preserve confidentiality, we will deidentify data for both peers and participants using a numeric code. The participants will have the researcher provide credentials for the smartphone app that will not include their names, and we will encourage the participants to use phone passwords.

Participants will be paid US $50 for attending the first session, US $5 per day for answering the EMA reports (at least 2 of 4 of the morning and random reports per day), and US $40 for attending the second session. The participants will also receive a weekly bonus of US $20 if they complete at least 80% of the random and morning reports. The most they can receive for participation is US $255. Peer participants will be compensated US $30 for each week they carry the beacon and answer the weekly survey questions, and US $10 for returning the beacon to the research team, so the most they can receive is US $100. All compensation will be provided in the form of an Amazon e-gift card.

We prioritized 4 criteria in the selection of the beacon used in this study: signal strength, robustness of the application programming interface, size and convenience of carrying, and battery life. The expected functionality of the beacon is primarily advertising (ie, one-way communication comprising transmission of small packets of data over fixed time intervals for detection and localization by a receiver—here, the EMA app used by the participants) [40]. Given these requirements, we selected BLE, an extension of the traditional Bluetooth protocol. Using BLE facilitated the optimization of our first criterion, signal strength. The Bluetooth protocol includes a feature called Received Signal Strength Indication, an indicator of the signal power received by a device detecting BLE signals. This feature, together with the specifications of the transmission source hardware, enables the computation of approximate positioning in the natural environment, including the estimation of distance [41,42]. Many hardware vendors provide these features; a subset of these vendors provides open, nonproprietary documentation of these values [43] and the ability to interface directly with the beacons through a robust application programming interface, our second criterion. After reviewing options, conducting testing, and consulting with the app developer, we selected Kontakt.io, a company with beacons that met the first 2 criteria and have form factors that can be attached to a phone or keyring to ensure that it is carried consistently. We extensively tested the options available from Kontakt.io and determined that the asset tag was most reliably detected by our app and by generic BLE scanner apps. Its battery life is 6 to 12 months and can be monitored on the internet; therefore, even with reuse, there should be no missing data attributable to a depleted battery.

We initially investigated whether we could build the system such that the Bluetooth on the peers’ phones would be detected by the app on the participant’s phone. For this, an app was needed that could use the BLE functionality within the participant phone to detect and identify the peer phone and prompt the participant to respond within the EMA app. One problem with using the peer phone as the BLE transmitter is that different Bluetooth hardware installed in different phones will report differing RSSI values for the same physical distance since this metric is contingent on the strength of the signal being sent out by the original device. This increases the complexity of the programming logic and would add error into what is a simple threshold check for beacons. Another issue is that we were unable to identify any phone-to-app software with an SDK available to use with our EMA app, whereas beacon detection SDKs were available. There were other considerations, including that in early developmental work concerns were raised by peers about installing an app on their phone, but the most critical were that the resources needed for phone-to-app detection were higher than the beacon-to-app model due to the initial development process, variability of operating systems and hardware, and required ongoing maintenance when relying on operating systems that evolve over time. The key benefits of beacon-to-app detection are the consistency of the technology and lower development costs when using an existing SDK.

The protocol for peer proximity detection and subsequent triggering of reports involves the detection of transient encounters (ie, incidental, brief social interactions between the participant and a peer identified through signal detection), their conversion into actual encounters (ie, meaningful social interactions differentiated from incidental encounters using a time criterion), and their termination as end encounters (ie, discontinuation of meaningful social interaction; refer to Figure 3 for a representation of the process). The EMA app continuously scans the participants’ environments for peer beacons. A transient encounter is recorded when the BLE proximity detection service integrated into our EMA app detects a beacon, defined as detecting a signal from a peer beacon that is at least as strong as the Received Signal Strength Indication criteria that correspond to our proximity criterion (ie, 15 ft, 4.6 m). The peer beacon advertising interval, which is the frequency at which beacons send out signals, was set to 1000 milliseconds (1 second) to ensure that the detection corresponds closely to real-world interactions. However, given that the detection of every signal from the peer beacon by the participants’ device during the initial encounter period is not guaranteed, a window of time for the detection of this signal is needed to ensure that detection occurs (ie, that it is not missed, resulting in a false negative); this window was set at 2 minutes for the transient encounter.

A transient encounter is converted into an actual encounter when the beacon has been detected for at least 15 minutes (our definition of meaningful interaction) without being undetected (ie, gone) for >2 minutes. A signal-contingent report will be triggered upon the conversion of a transient encounter to an actual encounter. Critically, the algorithm that determines triggering by beacon proximity runs separately for each peer participant, such that a transient and actual encounter with a peer beacon can be initiated even when the participant is in an actual encounter with another peer. Given that there will be 3 peers carrying beacons, it is possible that up to 3 reports could be triggered at a time, although we do not anticipate that this will happen frequently. In addition, given our encounter parameters that require 60 minutes of nondetection before another encounter with the same beacon would occur (refer to the subsequent section for explanation), we do not expect the number of signal-contingent reports to be overwhelming but will evaluate this closely.

A separate criterion to end an actual encounter after 60 minutes of nondetection (vs 2 minutes for a transient encounter end) was selected. We selected 60 minutes to reduce spurious nondetection and accommodate behaviors such as going to the restroom or being in different rooms at a party (which may still be part of an ongoing meaningful interaction despite not meeting the proximity criterion). Although the duration of the time criteria (ie, 15 minutes for the actual encounter and 60 minutes for the end encounter) were somewhat arbitrary, the evaluation of the sensitivity and specificity of the criteria via concordance with self-report is a goal of the study. Subsequent work can trial different definitions based on study findings, as well as what contact is truly influential and whether the length of influential contact varies by relationship type. Table 2 presents our initial criteria (far-right column) based on the best judgment, but the criteria are modifiable within the researcher-accessed interface.

There are several technology-related considerations for the detection of meaningful interactions. First, an a priori definition of a meaningful social interaction had to balance sensitivity for detecting such events (addressing the feasibility of detecting social interactions) with specificity in excluding incidental, nonmeaningful interactions (and reducing the burden of responding to multiple signal-contingent reports). However, our a priori criterion of requiring 15 minutes for a transient encounter to be converted into an actual encounter will miss brief but meaningful interactions (eg, consuming a shot of hard alcohol together, offering alcohol). Importantly, we designed our protocol to minimize missing data associated with such events by including the assessment of past-hour peer presence in our random reports and past-day peer presence in our morning reports. This design will allow us to cross-tabulate the occurrence of self-reported interactions of even short duration (as recorded in the EMA report data set) with the occurrence of all beacon detections, including transient encounters (as recorded in the Beacon Encounter data set).

Data produced by the app, including information about encounter events, participant self-reported data, and metadata, are stored in several data sets. These data sets are supplemented by postparticipation self-report data from (non-EMA) surveys and semistructured interviews. Table 3 contains a description of the data sources; Table 1 links the data sources with the study goals and methods to the evaluate goals.

Further information about the source data sets are presented in the Multimedia Appendices 1-5.

This data set contains information about the app version used and (morning, random, beacon-triggered) report items that are programmed into the app. It also contains event types (eg, app opened and app synced) and errors (eg, when the operating system denies permission to the app). We will use information from this data set to determine that the app was installed correctly and that it was functioning as expected during the study.

Variables include participant ID, beacon ID, start and end timestamps of transient and actual encounters, the timestamp when the transient encounter was converted into an actual encounter, and the timestamp for when the report notification was sent. A unique session ID links the elements (start and end) of given (transient and actual) encounters.

Variables include participant ID and types of events (eg, report start, report submit, and report notification) with timestamps. The report start and submit timestamps are present for all reports, including random, morning, and signal-contingent reports. Report notification timestamps (1) duplicate the timestamp of the transient-to-actual conversion reported in the Beacon Encounter data set (which triggers a notification) and (2) indicate whether other notifications are for random or morning reports.

Variables include session ID, report type (ie, random and morning), and timestamps when timed notifications and reminders were scheduled to be sent.

Data include participant responses to items in the signal-contingent, random, and morning reports, including indicators of who among their peers is or was present and self-reports about app functionality. For example, in each report, we ask, “Who did you interact with in person for at least 15 minutes?” The report type and timestamp will be used to ensure that data responses are aligned with information from other data sets and reports.

Data from the postparticipation interviews and the SUS will be used to evaluate the app’s functionality. Participant interviews will also be used to investigate identified discrepancies between the beacon-derived data and participant reports (ie, validity) and will be supplemented with weekly survey day-level reports from peers about their proximity to participants.

We will confirm the detection of the 3 beacons by the participant’s phone during the orientation. We expect to observe smartphone notifications for each beacon when the transient encounter is converted into an actual encounter (after 15 minutes). If notifications are not observed, we will examine the Beacon Encounter data set to determine whether transient encounters are being recorded (ie, whether the beacon is detected by the app) without being converted into an actual encounter. Functionality will be evaluated with 3 metrics: (1) the proportion of participants whose phones detect all beacons during the orientation, (2) the proportion of beacons detected by participant phones, and (3) the latency between exposing the participant phones to the beacons and the start of a transient and actual encounter. These observations will be systematically recorded and aggregated across beacons and participants.

Data from the Beacon Encounter data set will be used to evaluate functionality in two ways: (1) the proportion of actual encounters for which a signal-contingent notification was shown as sent by the server in the Beacon Encounter data set, and (2) the mean latency in minutes between the conversion to an actual encounter and the sending of the signal-contingent notification. The functionality of notifications for random and morning reports will not be evaluated, as these are commonly used in EMA and are fully functional in the app.

The app log, the EMA data, and the end-of-study interview and survey will be used to assess the participant-experienced functionality. The app log contains details about the events that have occurred within the app, including information about app crashes and app reinstalls. Using data provided by participants in the morning report, participant-related functionality will be determined as follows: (1) the total count (ie, person-days) of participant-reported suspected functionality problems, (2) the person-level proportion of days of suspected functionality problems, and (3) aggregated item-level and overall mean scores on the adapted SUS. Open-ended feedback will also be obtained in the morning report as well as in the end-of-study interviews.

The manufacturer, model, and Android operating system of the participant devices will be examined as moderators of the above metrics of functionality. The variables will be evaluated using a series of Mann-Whitney U tests (for means and counts) and chi-square tests (for comparing proportions) for each metric. Considering the small sample size, the groups will be driven by the sample of the device itself. For instance, the manufacturer could be binned to Samsung (or potentially Google) versus all other manufacturers; the model could be binned to currently supported (ie, receiving ongoing feature and compatibility updates) versus legacy; and the operating system could be binned to Android 13 (the newest) versus Android 11 or 12 (operating systems that were used during app development). Independent of group comparisons, descriptive findings on functionality will be aggregated for each manufacturer and operating system version.

We define validity as the concordance between encounters recorded in the Beacon Encounter data set and participant reports of peer presence recorded in the EMA reports (Table 4).

False negative beacon detections will be evaluated in a series of steps: First, we will compute the proportion of (1) days and (2) random reports in which a participant reported peer presence (from the EMA data set), but a corresponding transient or actual encounter does not exist (from the Beacon Encounter data set). If a transient encounter, but not an actual encounter, is recorded, we will compute (3) the proportion of these false negative events that occurred because of the a priori selection of 15 minutes as the threshold delineating a transient versus an actual encounter (based on timestamps of encounter events in the Beacon Encounter data set). For the false negative events that are not associated with a transient encounter, we will further attempt to delineate the reason underlying this false negative as either technology-related (the peer was carrying the beacon but the beacon was not detected) or compliance-related (the peer was not carrying the beacon) by integrating self-report data on compliance from the peer weekly surveys. If sample size and base rates allow, we will also fit a series of generalized linear mixed models [44] regressing concordance at the person level (eg, sex and age) and proximal prior event level (eg, context and alcohol use) predictors to identify systematic factors associated with detection failure. False positive beacon detections, as indicated by the triggering of a signal-contingent report when the peer beacon is not present, have never occurred in preliminary testing. Given the factors needed to incur a false positive detection, which should only occur if beacon information was entered incorrectly by the research team, we believe that such events are highly unlikely. However, it is possible that a notification could be delayed by the operating system or other action (eg, if the index participant phone is off), which would result in the participant report being delayed, and thus the participant report would not confirm the peer presence. Beacon detection also could occur when a peer was present but the participant was not aware (eg, at a large party) or if the peer left the area before the participant answered the report. We will compute the proportion of signal-contingent reports in which participants deny a past-hour peer presence. We expect that the participant interviews and the peer surveys will be informative about the conditions under which false positives occur and will improve our understanding and measurement of peer proximity and influence. Ultimately, the detection of an encounter by the protocol when such an interaction did not occur from the participant’s perspective provides critical information necessary for the computation of the specificity and positive predictive value of our detection protocol.

With various momentary assessment reports and passive data collection from multiple peers, the source of missing data is important to identify. We expect to have missing data owing to technical issues for the following reasons: (1) the beacons could stop sending a signal because of low battery or hardware failure; (2) the app could crash or be unable to send or receive data; (3) the phone operating system could update, resulting in the app or phone features not working as expected; or (4) the software detection algorithm may stop identifying encounter start and end signals. Missing data may also be because of participant or peer noncompliance, including the following: (1) participant nonresponse to EMA reports, (2) participant changing phone settings or status such that the detection of beacon signals or notifications is interrupted, or (3) peer failure to carry the beacon. Items in the morning report, postparticipation surveys and interviews, and the peer weekly survey will capture times when the participant or peer is aware of these issues occurring. While imperfect, this information should allow us to characterize situations in which the reason for missingness is known and thus maintain the missing-at-random assumption. Situations in which we are not confident about the reason for missing data will be investigated for systematicity using proximal prior predictors in the EMA data set to further maintain the missing-at-random assumption.