Project Details

The Project Details section of JUMP provides the user with overall project information.  It is a good place to review various details that are to be incorporated into the survey, to confirm they are correct, or possibly see that they still need to be provided.  The one very different section is the Link page, which provides access to the various survey links.

Project Details is accessed from the main survey card by clicking the briefcase icon (which will indicate Project Details, if you mouse over it).  Upon entering Project Details, the blue sidebar will show the available options, with “General” being the default selection.  Sidebar menu items include the following:

• General
• Links
• Data Security
• Data Quality
• Quotas and Reporting
• Language Overlays
• Sample

General

The General window has four main sections:

1. Project Timelines: These are the timelines that we are aware of. It is often helpful to review these to make sure that we have the complete and correct timeline goals.
2. Overall Progress: This section shows a quick overall count of Completes, Terminates, and OQs, once the survey has begun fielding. While more detailed information is available using some of the other available sections/tools, if all you need is a check for the overall number of Completes, this is the quickest resource (requiring only one click to the page).
3. Team: This section shows the Jibunu PM and anyone outside of Jibunu that has been given access to the project. Their role is also specified, typically Main Contact or Sample Provider.  Main contacts are generally provided full access to the various sections, reports, and data available in JUMP.  Sample Provider access is typically limited to their specific links, limited reports that only show counts associated with their efforts, and no access to raw data.  Access per user is highly customizable, just needing to be requested/applied through the Jibunu PM, if non-standard.
4. Project Notes: When important information is added to this section, the Jibunu PM will usually notify the user that it is available.

Links

This is probably the most frequently used page in this section, as it provides access to the survey links.  It is our policy not to send links via email, due to confidentiality and security reasons.  Instead, we provide secure access to the links, and you then have the ability to copy-and-paste them, to share as needed.  Some projects may have numerous links for various sample providers, and/or various languages/countries.  If the links incorporate a special variable that requires a specific value, that information is often noted with the link.

Here are some helpful things to know, regarding the different links:

1. Testing Links
   1. Test links are the initial delivery item.
   2. They provide additional testing tools and pages that do not appear when the final Live link is used.
   3. Sometimes end-clients would like to test using a “live looking” test link. Please discuss this with your PM, if one is needed.
   4. Data generated while using a test link is available until a survey is set live. At that point, any further test link data does not appear with the data collected from actual respondents.
   5. The test link for programming approval should not be confused with a test link for sample provider testing. Sample providers most often need to test that their redirects are functioning properly, and this can only be done with a Live link.  (Their test data, using the live link, would then need to be cleared.)  To be clear, “test” links are not provided to sample providers.  They test with the actual Live links.
   6. Test links always reflect the same programming as a Live link (although the Test link is created prior to the Live link becoming available).
2. Live Links
   1. Once the programming has been approved for the test link, and any required, additional information is provided/implemented, such as redirects, a Live link can be created.
   2. There is a process though, for setting a survey live, which includes steps such as automated testing of quotas, and setting up reporting. Both of these items must wait for the initial programming to be final or very close to final, before they can be completed.  While we try to do as much up-front work as possible, it is important to note that setting a survey live is not as simple as flipping a switch, and sufficient time is required to ensure that everything is correct and ready to go.  This is highly project dependent, but it is typically less than a half day.
3. Staging Links
   1. A Staging link is used when changes are necessary, after the survey is live and in field. Changes are made on the Staging link for testing/approval, prior to being pushed live.  The changes are not seen/tested using the Test link, as they will not appear on the test link until the changes are pushed live, from the Staging link.  You will be notified, if you are to test using a Staging link, for live changes.

Data Security

1. Personally Identifiable Information (PII): While it is best not to store any PII, sometimes it is required. This section provides some general information about PII and indicates whether we are anticipating any to be collected by the survey or provided to us in a sample file.
2. Privacy Policy: The default is to use our privacy policy, as one is required for every survey. Please let us know if an alternative privacy policy is to be used.  This is typically a sample provider request/requirement.
3. Data Retention: Our standard policy is to purge survey data, six months after it has been closed, unless otherwise notified. It is also our policy to close surveys that have been inactive for more than 60 days.  Alternate data retention timing can be specified, if needed.

Data Quality

Jibunu currently applies RelevantID (RVID), as requested, to check for suspected duplicate and fraudulent respondents.  It can be used to Terminate or only flag suspected duplicate and/or fraudulent respondents.  A request for RVID is noted in this section.

There is also a note indicating that there are issues with using RVID in China, as the necessary communication steps do not always function.  It should never be used in China to Terminate, as there is the potential then for most respondents to be terminated.  It can be used to flag suspected duplicate and fraudulent respondents, but the information may only get applied to a very small percentage of respondents.  As such, its use is not currently recommended for surveys in China.

Quotas and Reporting

1. Quota Specifications
   1. Overage Tolerance: This is a safeguard against quota overages that works by limiting the number of respondents allowed to qualify for a quota group. This limit is the quota group’s maximum, plus a specified percentage of that maximum (default is 10% for consumer studies and 0% for medical studies). If there are enough qualified in-progress respondents to fill the quota (+10% if the study has 10% overage tolerance), then all other respondents who attempt to qualify for that quota group will be over-quota in order to prevent overages. Respondents with a status of OTQ (over tolerance quota) were over-quota due to overage tolerance.
   2. Inactivity Recheck Timer: Qualified in-progress respondents will take up a quota spot as long as they are actively taking the survey (default is within the last two hours or another specified period) or if they complete. After two hours of inactivity, the respondent will be flagged as “qualified, but suspended for inactivity”, or -302. The 2-hour limit is the inactivity recheck time. Inactivity recheck provides a safeguard against quota overages, based on the amount of time qualified incompletes have been inactive in the survey. In addition, it limits the amount of time a qualified incomplete that may never complete the survey will count toward a quota check with overage tolerance.
2. Simple Counter: This is the most commonly used report in the Report Viewer tool. By default, it is set up to provide counts for Completes, Terminates, and Abandons, as well as quota grids.  Additional grids can be set up, if specified, to make tracking the study easier while in field.  These are noted here, as we are made aware of the special need.
3. Dummy Data: If dummy data has been requested, the details are listed here.
4. Additional Reporting Services – If additional reporting services have been requested, they are listed here.
5. Data Matching: If data matching is required on a subsequent wave of a study, it is noted here.

Language Overlays

If a study has language overlays, it will be noted here.  If Jibunu has been asked to manage the translation work, that is also noted.  Most often we are provided with the translations which are then overlayed into the survey.  Overlays are not separate surveys, but instead, they are the alternate translated text that is shown, for the main programmed survey.

Overlays are handled using XLIFF files, which is a more automated importation process, or using Word documents which is a more manual process.  XLIFF files can be handled much quicker than Word documents for overlays, but it is important that the translator knows how to properly handle such files, as improper translation work can negate the normal time savings.

This section also indicates the overlay languages that we are expecting to implement.

Sample

This section provides information on the sample provider(s) that we are aware will be used.  Redirect or End-text information that has been provided is listed here.

Updated 3/1/23